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Mobile  Assisted  Security  in  Wireless  Sensor  Networks 


We  have  built  a  comprehensive  testbed  for  mobile  assisted  sensor  network  research.  Two  mobile 
robots,  sensors  and  servers  that  can  run  large  scale  simulations  are  now  available  for  students  working 
on  the  project.  PhD  students  Ali  Tekeoglu  and  Andrew  Wichmann  are  partially  supported  by  the 
project  and  they  both  graduated  recently.  Over  the  last  year  we  had  publications  at  International 
workshop  on  robotic  sensor  networks,  IEEE  11th  international  conference  on  Mobile  Ad  Hoc  and 
Sensor  Systems,  INFOCOM  Multimedia  Cloud  Communication  Workshop. 

1  Equipments  Acquired  For  Sensor  Networks  Lab 

We  have  purchased  2  Pioneer-AT  Mobile  Robots  for  Experiments.  The  PIONEER  3-AT  is  a  highly 
versatile  four  wheel  drive  robotic  platform.  Powerful,  yet  easy  to  use  reliable,  yet  flexible,  P3-AT  is  a 
popular  team  performer  for  outdoor  or  rough-terrain  projects.  P3-AT  offers  an  embedded  computer 
option,  opening  the  way  for  onboard  vision  processing,  Ethernet-based  communications,  laser,  DGPS, 
and  other  autonomous  functions.  8  forward  and  8  rear  sonar  sense  obstacles  from  15  cm  to  7  m. 
P3-AT’s  powerful  motors  and  four  knobby  wheels  can  reach  speeds  of  .8  meters  per  second  and  carry 
a  payload  of  up  to  12  kg.  We  have  purchased  2  Memsic  Classroom  kits.  Classroom  kits  are  ideal  for 
getting  students  up  and  running  quickly  and  economically.  To  support  10  lab  stations,  a  collection  of 
30  wireless  modules,  20  sensor  and  data  acquisition  boards,  10  gateway  and  programming  boards  are 
included.  The  Classroom  Kit  is  available  in  2.4GHz.  We  have  also  purchased  3D  robotics  UAV  to  be 
used  as  an  aerial  node  to  communicate  with  the  mobile  robots  on  the  ground. 

2  Personnel  Supported  By  The  Project 

Ali  Tekeoglu  is  a  PhD  student  working  on  secure  multimedia  delivery  He  defended  his  dissertation  in 
summer  2015.  Andrew  Wichmann  is  working  on  task  allocation  and  path  planning  and  He  defended 
his  dissertation  in  spring  2015. 

3  Technical  Manuscripts  From  The  Project 

A  couple  of  technical  manuscripts  that  resulted  from  the  project  are  attached  to  the  progress  report. 
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Coordinating  Robots  for  Connectivity  in  Wireless 

Sensor  Networks 


Baris  Tas  and  Ali  Sam  an  Tosun 
Department  of  Computer  Science 
University  of  Texas  at  San  Antonio 
San  Antonio,  TX  78249 
{btas, tosun}  @cs.utsa.edu 


Abstract — Mobile  robots  improve  scalability  and  performance 
of  wireless  sensor  networks.  Protocols  for  many  services  including 
data  collection,  localization,  topology  control  and  security  in 
wireless  sensor  networks  include  mobile  robots.  Using  a  single 
robot  limits  the  scalability  and  performance  and  multiple  robots 
are  used  as  a  result.  When  multiple  robots  are  deployed,  it 
is  desirable  to  have  the  robots  connected  to  provide  improved 
services.  However,  coordinating  the  robots  optimally  to  achieve 
connectivity  among  them  is  not  trivial.  We  use  computational 
geometry  techniques  to  achieve  connectivity.  We  use  the  concept 
of  Frechet  distance  between  curves  to  synchronize  the  robots 
for  connectivity.  We  extend  the  idea  of  Frechet  distance  to 
multiple  curves  where  each  curve  is  the  path  of  a  robot.  We 
analyze  the  proposed  idea  theoretically  and  show  that  the  theory 
can  not  be  applied  directly  due  to  limitations  on  robot  speed 
and  speed  changes.  Therefore,  we  propose  a  practical  approach 
where  maximum  robot  speed  is  bounded  and  speed  changes  is 
limited.  Simulations  show  that  the  connectivity  among  the  robots 
is  maintained  when  the  robots  follow  the  movement  pattern  based 
on  the  Frechet  distance  between  the  paths  of  consecutive  robots. 


I.  Introduction 

A  wireless  sensor  network  (WSN)  consists  of  potentially 
hundreds  of  sensor  nodes  and  is  deployed  in  an  ad  hoc 
manner  for  collecting  data  from  a  region  of  interest  over  a 
period  of  time.  Even  though  the  technology  is  new,  WSNs 
received  an  enthusiastic  reception  in  the  science  community 
as  WSNs  enable  precise  and  fine-grain  monitoring  of  a  large 
region  in  real-time.  Some  examples  of  successful  large-scale 
deployments  of  WSNs  to  date  are  in  the  context  of  ecology 
monitoring  (monitoring  of  micro-climate  forming  in  redwood 
forests),  habitat  monitoring  (monitoring  of  nesting  behavior  of 
seabirds),  and  military  surveillance  (detection  and  classifica¬ 
tion  of  an  intruder  as  a  civilian,  soldier,  car,  or  SUV). 

To  improve  the  scalability  and  performance  of  WSNs,  there 
has  been  a  flurry  of  work  on  employing  a  mobile  node  for  data 
collection.  The  data  mules  [1  ]  work  exploit  random  movement 
of  mobile  node  to  opportunistically  collect  data  from  a  sparse 
WSN.  Here,  the  nodes  buffer  all  their  data  locally,  and  upload 
the  data  only  when  the  mobile  node  arrives  within  direct  com¬ 
munication  distance.  Zebranet  [2]  system  uses  tracking  collars 
carried  by  animals  for  wildlife  tracking.  Data  is  forwarded 
in  a  peer-to-peer  manner  and  redundant  copies  are  stored  in 
other  nodes.  Shared  wireless  info-station  model  [3]  uses  radio 
tagged  whales  as  part  of  a  biological  information  acquisition 
system.  Mobility  of  the  mobile  node  is  not  controlled  in 
these  approaches.  Mobile  element  scheduling  (MES)  work  [4] 


considers  controlled  mobility  of  the  mobile  node  in  order  to 
reduce  latency  and  serve  the  varying  data-rates  in  the  WSNs 
effectively.  The  MES  work  shows  that  the  problem  of  planning 
a  path  for  the  mobile  node  to  visit  the  nodes  before  their  buffers 
overflow  is  NP-complete.  Heuristic  based  simple  solutions  are 
proposed  to  address  this  problem  [4]— [6] .  Data  salmon  [7] 
constructs  a  spanning  tree  and  moves  the  mobile  base  station 
on  this  tree  to  optimize  the  cost  of  retrieval.  To  reduce  the 
size  of  the  path  the  mobile  node  travels,  rendezvous  points  are 
used  as  regional  collection  points  and  the  mobile  node  collects 
the  data  from  the  rendezvous  points  [8],  Readers  are  referred 
to  [9]  for  using  a  mobile  element  in  data  collection. 

Multiple  robots  are  employed  in  WSNs  to  enhance  the 
monitoring  of  an  environment.  Using  multiple  robots  brings  its 
own  challenges.  One  challenge  is  to  preserve  the  connectivity 
among  them.  Having  connected  robots  improves  the  services 
the  network  offers  in  terms  of  more  efficient  and  new  protocols. 
Also,  the  connectivity  among  the  robots  leads  to  more  secure 
protocols.  There  has  been  some  work  in  the  literature  for 
providing  connectivity.  The  connectivity  between  the  base 
station  (BS)  and  a  robot  exploring  the  environment  is  main¬ 
tained  using  intermediate  robots  in  [10],  [11].  The  coordinated 
motion  planning  problem  where  robots  need  to  cooperate  is 
studied  [12]— [  14].  A  distributed  algorithm  that  preserves  the 
connectivity  of  a  team  of  robots  with  limited  communication 
among  the  robots  is  proposed  in  [15].  Periodic  connectivity 
where  the  robots  are  connected  at  fixed  intervals  is  introduced 
in  [16].  Periodic  connectivity  is  desired  for  scenarios  where  the 
robots  explores  the  environment  individually  at  some  points 
and  then  regains  the  connectivity  to  share  their  information. 

We  focus  on  a  scenario  where  multiple  robots  as  a  team 
monitor  an  area  of  interest.  Our  aim  is  to  have  a  connectiv¬ 
ity  among  the  robots  whose  paths  are  pre-determined.  Pre¬ 
determined  paths  are  frequently  used  for  monitoring  an  area 
since  the  use  of  pre-determined  paths  has  advantages  over  non- 
determined  paths.  When  a  robot  traverses  a  region  multiple 
times,  it  can  optimize  its  path  according  to  the  regions  where 
a  sensor  exists  or  not.  It  does  not  have  to  travel  to  empty 
areas.  When  the  mapping  of  the  environment  is  known,  the 
paths  are  set  so  that  the  robots  avoid  obstacles  such  as  rocks 
and  impossible  regions  such  as  lakes  where  robots  might  get 
stuck.  Also,  it  is  easy  to  estimate  energy  use  and  transmission 
power  when  the  paths  are  known.  Finally,  managing  multiple 
robots  is  easier  when  pre-determined  paths  are  used.  Also,  pre¬ 
determined  paths  serve  as  a  first  step  to  solving  unrestricted 
case  where  no  constraints  are  put  for  mobile  movement. 


Frechet  distance  ( D  p)  is  used  to  coordinate  the  robots  in  a 
connected  way  optimally  in  terms  of  transmission  range.  The 
solution  of  Df  between  two  curves  gives  locations  of  point 
pairs  -  one  point  is  on  the  first  curve,  and  the  other  point  is 
on  the  second  curve  -  where  the  distance  between  the  points 
in  a  pair  is  less  than  the  similarity  value  between  the  curves. 
The  robots  move  along  the  curves  and  the  movement  pattern 
of  the  robots  is  based  on  the  solution  pairs.  Di?  is  a  similarity 
measure  between  two  curves.  It  is  introduced  by  Frechet  [17]. 
It  has  been  used  in  many  applications  including  matching  of 
time  series  in  databases  [18],  map-matching  vehicle  tracking 
data  [19],  [20],  moving  object  analysis  [21],  [22],  speech 
recognition  [23],  and  song  identification  [24], 

The  rest  of  the  paper  is  organized  as  follows.  We  describe 
the  system  model  in  Section  II.  The  foundations  of  our 
proposal  which  include  the  Frechet  distance  is  studied  in 
Section  III.  Theoretical  aspects  of  the  system  are  shown  in 
Section  IV.  We  provide  simulation  results  in  Section  V.  Other 
system  issues  are  discussed  in  Section  VI,  and  we  conclude 
with  Section  VII. 

II.  System  Model 

The  WSN  in  this  work  consists  of  t  sensors  and  n  robots 
(r,  is  a  robot  where  i  is  the  id  of  a  robot  and  1  <  i  <  n). 
The  sensors  are  statically  deployed  in  a  bounded  region  of 
Ax  A.  The  area  possibly  contains  obstacles.  The  robots  move 
on  polygonal  curves  as  a  team,  monitor  the  area,  and  retrieve 
information  from  the  sensors.  The  paths  of  the  robots  are  set 
by  the  base  station  (BS).  After  the  robots  collect  information 
about  the  environment,  they  return  back  to  the  BS,  and  transmit 
their  data  to  the  BS.  After  the  batteries  of  the  robots  are 
recharged,  they  start  the  next  round  of  monitoring.  The  BS 
can  set  new  paths  to  the  robots.  The  robots  are  connected 
all  the  time.  When  this  connectivity  is  guaranteed,  efficient 
and  more  robust  protocols  can  be  designed  improving  the 
security  of  the  services  the  network  offers.  For  example, 
events  such  as  fire  can  be  recognized  faster.  The  robot  sensing 
the  event  can  communicate  with  the  other  robots  instantly. 
Moreover,  attacks  against  the  network  can  be  minimized  using 
multiple  connected  robots  since  more  information  about  the 
environment  is  collected  at  a  time. 


III.  Foundations 

As  a  starting  point  for  achieving  the  connected  multiple 
robots,  we  first  consider  a  movement  pattern  which  guarantees 
the  connectivity  between  two  robots  whose  paths  are  pre¬ 
determined.  Our  aim  is  to  provide  the  connectivity  using  the 
shortest  transmission  ranges. 


(a)  (b)  (c) 

Fig.  2.  How  to  coordinate  two  robots  optimally. 

Figure  2  gives  an  idea  of  how  to  coordinate  two  robots 
with  optimal  transmission  ranges.  For  all  the  sub-figures,  the 
robots  have  to  move  in  a  way  so  that  their  y-coordinates 
should  be  the  same  at  all  times  to  achieve  the  minimum 
distance  in  between.  If  the  y-coordinates  differ,  they  have  to 
have  longer  transmission  ranges  to  communicate.  This  simple 
observation  reveals  that  there  has  to  be  a  coordination  between 
the  robots  possibly  requiring  changes  on  their  speed  to  provide 
the  connectivity. 

A.  Frechet  Distance 

We  use  the  Frechet  distance  (D/.  j  to  coordinate  multiple 
robots.  The  Dp  is  a  similarity  measure  between  two  curves. 
The  D/,'  between  two  curves  can  be  defined  informally  using 
an  analogy  to  a  man  walking  a  dog  on  a  leash.  The  man  moves 
in  one  curve,  and  the  dog  moves  in  another  curve.  Their  speed 
may  vary,  but  they  can  not  move  backwards.  The  length  of 
the  shortest  possible  leash  required  until  both  complete  their 
curves  is  the  Di?  between  the  curves.  The  Dp  considers  the 
location  and  ordering  of  the  points  along  the  curves.  In  our 
case,  one  robot  will  take  the  role  of  the  man,  and  the  other 
robot  will  take  the  role  of  the  dog. 


\\  it  fit  it  I  -it 


Fig.  1 .  System  Model 


Figure  1  demonstrates  a  possible  scenario.  Sensors  are 
deployed  in  the  area.  The  robots  follow  their  pre-determined 
paths  monitoring  the  environment.  The  polygons  represent 
the  obstacles,  so  the  robots  can  not  pass  through  them.  The 
robots  are  synchronized  to  be  connected  using  Frechet  distance 
solutions.  It  is  also  possible  to  have  another  team  of  connected 
robots  monitoring  and  enhancing  the  services  of  the  network. 


Fig.  3.  Parametrization  of  P  :  [0,  5] 

The  first  step  to  compute  the  Dp  between  two  curves 
is  to  approximate  a  curve  by  a  polygonal  curve  which  is 
a  curve  entirely  made  up  of  line  segments.  Therefore,  we 
mean  a  polygonal  curve  whenever  we  mention  a  curve.  A 
polygonal  curve,  P  :  [0,  JV],  is  a  continuous  and  piecewise 
linear  curve  made  up  of  N  connected  segments.  N  is  the 
length  of  the  curve.  Using  a  parameter  a  £  R,  P  :  [0,  N]  can 
be  parameterized  so  that  P{a)  refers  to  a  point  on  the  curve. 
Figure  3  shows  the  parameterization  of  the  curve,  P  :  [0,  5]. 

Time  concept  also  needs  to  be  parameterized  to  model  the 
man-dog  example.  Assume  that  the  man  is  following  a  curve 
P  :  [0,  N\,  and  the  dog  is  following  a  curve  Q  :  [0,  M\.  Then, 


the  position  of  the  man  and  the  dog  can  be  expressed  as  a 
function  of  t  by  P(a(t)),  and  Q((3(t)),  where  ct(0)  =  0, 
a(l)  =  N,  /3(0)  =  0,  /?(1)  =  M,  and  the  functions  a  and 
/3  are  continuous  and  non-decreasing  functions. 

Although  2-dimensional  space  is  considered  for  simplicity, 
the  following  definitions  for  Dp  between  two  curves  work 
for  arbitrary  dimensions.  Finally,  is  defined  formally  as 
follows  [25], 

Definition  1.  Let  V  denote  an  arbitrary  Euclidean  vector 
space.  Let  /  :  [a,  a'\  — >  V  and  g  :  [6,  b ']  — >  V  be  curves  where 
a, a', b,b'  £  R  and  a  <  a',b  <  b' .  Then,  Dp(f,g)  denotes 
their  Frechet  distance,  defined  as 


D f(/,3):  =  min  max  \\f(a(t))  -  g(P(t))\\ 

a[0,l]-v[a,a']  te[0,l] 

/3[0,1  ]->[&, 6'] 

where  a,  /3  range  over  continuous  and  increasing  functions 
with  a(0)  =  a,  a(l)  =  a',  /3(0)  =  b,  /?(  1)  =  b' . 


To  compute  the  13  p  between  two  polygonal  curves,  the 
following  decision  problem  is  considered.  Given  polygonal 
curves  P  and  Q,  and  some  e  >  0,  decide  whether  Df  <  e. 
Let  P  :  [0,p]  and  Q  :  [0,  q)  be  polygonal  curves  where  p  and  q 
are  the  number  of  edges  of  P  and  Q  respectively.  To  solve  the 
problem,  let’s  first  consider  the  case  where  p  =  q  =  1;  and  de¬ 
fine  the  free  space,  Fe  =  ( s,t )  £  [0,  l]2  |  d(P(s),Q(t ))  <  e, 
which  describes  all  pairs  of  points,  one  on  P  and  one  on  Q, 
whose  distance  is  at  most  e.  Figure  4  shows  line  segments  P, 
Q,  a  distance  e  >  0,  and  Fe  being  the  white  area  within  the 
unit  square  [25].  The  Ff  corresponding  to  the  line  segments  is 
the  intersection  of  the  unit  square  with  an  ellipse  (Its  proof  can 
be  found  in  [25]).  For  example,  the  ‘o’  in  the  white  area  of  the 
free  space  diagram  corresponds  to  the  points  represented  by 
‘o’s  on  the  curves  whose  pairwise  distance  is  less  than  e.  On 
the  contrary,  the  ‘  x  ’  in  the  gray  area  corresponds  to  the  points 
represented  by  ‘  x ’s  on  the  curves  whose  pairwise  distance  is 
greater  than  e. 


(a)  One  segment  curves  P,  Q 


- >  P 

(b)  Free  space  diagram 


Fig.  4. 

The  Ft  equation  is  extended  to  arbitrary  curves  P  :  [0.  p\ 
and  Q  :  [0,  q]  as  follows: 


Fe  =  ( s,t )  £  [0,p]  x  [0,?]  |  d(P(s),Q(t))  <  e  (1) 

Figure  5  demonstrates  an  example  of  curves  P  :  [0,  3],  Q  : 
[0,  3]  along  with  their  corresponding  free  space  diagram  for  a 


given  e  =  70.  A  point  on  the  free  space  diagram  corresponds  to 
a  solution  pair  on  the  curves.  For  example,  the  *□’  on  the  free 
space  diagram  corresponds  to  the  ‘D’s  on  the  curves.  Similarly, 
the  ‘o’  corresponds  to  the  ‘o’s;  and  the  ‘x’  corresponds  to 
the  ‘x’s  on  the  curves.  The  distance  between  the  ‘x’s  on  the 
curves  is  110,  the  distance  between  the  ‘o’s  on  the  curves  is 
70,  and  the  distance  between  the  ‘D’s  is  52.  The  distances 
between  the  points  (□,  o)  which  correspond  to  the  points  in 
the  white  area  in  the  free  space  diagram  are  less  than  the 
e  value,  whereas  the  distance  between  ‘x’s  is  greater  than  e 
since  the  corresponding  ‘  x  ’  in  the  free  space  diagram  is  in  the 
gray  area.  If  there  exists  a  monotone  curve  in  both  directions 
from  (0,  0)  to  (p,  q)  within  the  Fe  of  curves  P  and  Q,  we 
have  D/.  <  e.  In  other  words,  the  man  following  one  curve 
can  walk  his  dog  following  the  other  curve  with  a  leash  of 
length  e  referring  back  to  the  man-dog  example.  The  monocity 
condition  comes  from  the  fact  that  the  man  and  the  dog  can 
not  move  backwards.  If  the  monocity  condition  is  eliminated, 
then  the  problem  is  called  weak  Frechet  Distance. 


(a)  Free  space  diagram  (e  =  70) 
Fig.  5.  Frechet  Distance  between  curves. 


e  =  70 


(b)  Curves:  P,  Q 


In  order  to  solve  the  decision  problem,  Fe  values  are 
calculated  starting  from  e  =  0  to  the  smallest  e  value  which 
make  Fe  contain  a  monotone  curve  from  (0,0)  to  ( p,q ).  At 
that  point.  Dp  is  found  to  be  the  final  value  of  e.  However, 
a  more  clever  algorithm  is  achieved  using  the  technique  of 
parametric  search  on  some  critical  e  values.  The  runtime  of 
this  algorithm  is  0(pqlog(pq)),  and  its  details  can  be  found 
in  [25].  The  corresponding  free  space  diagrams  of  the  curves 
P  and  Q  from  Figure  5  for  e  values  67,  70  and  73  are  shown  in 
Figures  5,  and  6.  As  seen  from  the  figures,  Fe  gets  larger  as  e 
values  increase,  and  of  the  curves  is  70  since  the  smallest  e 
value  which  make  the  free  space  diagram  contain  a  monotone 
curve  from  (0,0)  to  (3,3)  is  70.  We  call  the  monotone  curve 
a  solution  curve  for  the  curves  P  and  Q  ( SpQ ). 


- >  P 

(a)  e  =  67.  No  solution 


Fig.  6.  Free  space  diagrams  with  different  epsilon  values. 


B.  Adapting  Frechet  Distance  to  Connectivity  Problem 

We  start  with  the  basic  case  where  the  coordination  be¬ 
tween  two  robots  is  considered.  Later,  we  extend  the  idea  to  the 
case  where  there  exist  arbitrary  number  of  robots.  A  solution 
curve  ( Se )  to  the  Frechet  distance  between  two  curves  is  used 
in  coordinating  two  robots  to  have  a  connectivity  between  the 
robots.  The  curves  are  assumed  to  be  the  paths  of  the  robots. 
Let  one  curve  be  P,  and  the  other  curve  be  Q.  Also,  assume 
that  Rp  is  the  robot  following  curve  P,  and  Rq  is  the  robot 
following  curve  Q.  A  point  on  Spq  in  the  free  space  diagram 
of  two  curves  corresponds  to  a  pair,  which  we  call  a  solution 
pair,  consisting  of  two  locations  on  the  curves.  One  location  is 
on  curve  P  and  the  other  location  is  on  curve  Q.  We  know  that 
the  distance  between  the  locations  in  a  solution  pair  is  less  than 
D  /.  ,  and  this  is  also  true  for  all  solution  pairs.  Therefore,  if 
the  transmission  ranges  of  the  robots  are  greater  than  Df,  the 
robots  are  guaranteed  to  be  connected  at  the  solution  locations. 
As  a  result,  a  movement  pattern  for  the  robots  is  driven  based 
on  the  solution  locations. 


Fig.  7.  Robot  movement  based  on  Frechet  Distance. 

Since  the  paths  of  the  robots  are  pre-determined,  D/- 
and  the  corresponding  free  space  diagram  can  be  computed. 
Figure  7  shows  two  paths  P[0  :  TV] ,  Q[0  :  M ]  and  their 
corresponding  free  space  diagram  where  TV  =  6  is  the  size 
of  curve  P,  M  =  4  is  the  size  of  curve  Q.  Consider  the  point 
on  curve  P.  Let  Param(pn)  be  the  parametrized  value  of 
the  point  (see  Figure  3  for  curve  parametrization).  The 
intersection  of  the  line  segment  ((Param(Pn),  0);  (Param(pn), 
M))  and  the  solution  curve  in  the  free  space  diagram  is 
represented  as  ‘d’  in  Figure  7(a).  The  x-coordinate  of  this 
point  is  Param(p  n)  and  the  y-coordinate  is  Param^Q  □)  where 
Param(Q  □)  is  the  parametrized  value  of  the  point  ‘D’  on  curve 
Q.  Using  this  value,  it  is  trivial  to  compute  the  xy-coordinates 
of  the  point  ‘D’  on  curve  Q.  Similarly,  ‘o’,  ‘x’,  ‘o’,  and  ‘+’ 
are  the  other  example  solution  pairs,  on  curves  P  and  Q.  The 
distances  between  the  points  in  each  pair  are  less  than  DP.  If 
the  robots,  Rp  and  Rq,  are  coordinated  so  that  they  reside 
at  the  pair  points  at  the  same  time,  they  are  guaranteed  to  be 
connected  at  these  points.  For  example,  assume  that  Rp  with 
constant  speed  passes  by  the  locations  ‘o’,  ‘x’,  ‘o’,  and 
*+’  on  curve  P  at  times  £□,  t0,  tx,  to,  and  t+  respectively. 
If  the  speed  of  Rq  is  arranged  so  that  Rq  passes  by  the 
locations  ‘o’,  ‘x’,  ‘o’,  and  ‘+’  on  curve  Q  at  times  t\j, 
to,  tx,  to,  and  t+  respectively,  then  it  is  guaranteed  that  the 
robots  are  connected  at  the  specified  points.  In  theory,  any 
point  on  a  curve  and  its  pair  point  on  the  other  curve  can  be 
computed  using  the  solution  curve  on  the  free  space  diagram 
and  continuous  connectivity  is  achieved. 


We  extend  the  case  where  there  exist  two  robots  to  the 
case  with  arbitrary  number  of  robots.  When  multiple  robots  are 
coordinated,  we  assume  a  simplified  version  where  the  paths  of 
the  robots  do  not  intersect  (the  case  where  the  paths  intersect 
can  be  dealt  with  solving  Frechet  distance  for  partial  curves). 
In  this  way,  the  idea  used  for  two  robots  can  be  applied  to 
every  two  consecutive  robots  in  a  chained  way.  Assume  that 
there  exist  three  robots,  Rp,  Rq,  and  Rp  following  the  curves 
P[0  :  5],  Q[0  :  6],  R[0  :  4]  respectively  as  shown  in  Figure  8(a). 
Consider  the  first  two  consecutive  robots  Rp  and  Rq.  The  free 
space  diagram  of  the  curves  P  and  Q  (FSD^P^)  is  given  in 
Figure  8(b).  Using  the  solution  curve  in  FSD^Pqy  solution 
pairs  on  the  curves  can  be  computed  as  discussed  in  the  two 
robot  case.  For  example,  for  the  locations  *□’,  ‘o’,  ‘x’,  ‘o’, 
and  ‘+’  on  curve  P;  their  corresponding  locations  on  curve 
Q  derived  from  the  solution  curve  in  FSD^pq^  is  shown  on 
curve  Q.  To  compute  the  corresponding  points  on  curve  R,  we 
make  use  of  Param^QQ) ,  Param(Qj0),  Param^Q  x),  ParamfQ  0n  and 
Paiam(g  +)  along  with  FSDrq  Ry  For  instance,  Param(p  ™  is  the 
intersection  of  the  line  segment  ((Param^o),  0);  (Param(Q ,n)>4)) 
and  the  solution  curve  in  FSD^q  Ry  Once  Param(p  n)  is  found, 
computing  the  xy-coordinates  of  the  point  on  curve  R  is 
trivial.  Finally,  when  the  speeds  of  the  robots  VRp,  VRq,  and 
VRr  are  arranged  so  that  the  robots  reside  at  points  *□’  on  their 
curves  at  time  t\j,  the  connectivity  is  achieved  at  locations  ‘Ill’s 
on  the  curves.  The  same  also  applies  for  the  ‘o’,  ‘x’,  ‘o’,  “+’ 
locations. 

1)  Coordinating  Multiple  Robots  in  an  Application:  The¬ 
oretically,  multiple  robots  are  guaranteed  to  be  connected  at 
all  times  when  all  solutions  from  the  free  space  diagram  is 
used.  However,  this  might  cause  too  many  changes  on  the 
speed  of  the  robots.  We  explain  this  in  detail  in  section  V.  To 
limit  the  speed  changes  for  robots,  we  coordinate  the  robots 
based  on  one  robot  ( Rbase )■  Only  the  vertices  on  the  path 
of  Rbase  are  considered  for  the  resulting  solution  points.  For 
example,  consider  that  robots  Rp ,  Rq  and  Rp  is  set  to  follow 
the  curves  P,  Q,  R  in  Figure  8(a).  If  Rp  is  picked  as  Rbase, 
then  the  vertices  of  curve  P  are  considered  as  solution  points 
and  the  corresponding  solution  points  on  the  other  curves 
are  computed  as  discussed  above.  This  results  in  connectivity 
when  the  robots  are  at  locations  □,  o,  x,  o,  +  on  their 
own  curves.  Any  robot  could  have  been  chosen  as  Rbase- 
If  the  application  requires  more  locations  where  the  robots 
are  connected,  additional  robots  are  picked  as  Rbase,  and  the 
solutions  from  each  setting  are  combined. 

IV.  Theoretical  Foundations 

In  this  section,  we  discuss  the  theoretical  aspects  of  our 
idea.  We  will  show  that  the  speed  of  the  mobile  robots  needs 
to  be  updated  during  traversal  to  follow  the  solution  curve. 
Consider  the  following  example. 

In  Figure  9,  when  robot  Rp  is  at  x,  robot  Rq  must  be  at 
a  and  when  robot  Rp  is  at  y,  robot  Rq  must  be  at  b.  In  the 
first  part,  when  Rp  travels  20  units,  Rq  travels  40  units  and 
in  the  second  part  when  Rp  travels  60  units,  Rq  travels  100 
units.  So,  even  if  Rp  has  constant  speed,  Rq  needs  to  update 
its  speed  during  traversal. 

Theorem  1.  Given  curves  C \  and  Gi,  a  solution  curve  Se 
in  Free  Space  diagram  FSD(Ci,C2)-  mobile  robots  can  follow 


(b)  FS_D(p  g) 


(c)  FSD^q  r^ 


Fig.  8.  Multiple  robot  movement. 
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Fig.  9.  The  speed  of  the  robots  needs  to  be  updated 


the  solution  curve  Se  by  setting  the  speed  on  curve  C2  relative 
to  the  speed  on  cur\’e  C\. 

Proof:  Solution  curve  Se  intersecting  current  cell  of  free 
space  diagram  can  be  represented  as  a  special  case  of  one  of 
the  following. 


So,  speed  on  C2  for  a  line  segment  with  speed  Vu  on 
Ci  is 


V2i  =  Vu 


H 

a|ei| 


•  Case  2:  Current  cell  of  free  space  diagram  follows 
a  complete  edge  of  C\  as  in  left  side  of  figure.  Let 
fraction  of  e2  in  current  cell  be  3. 

Line  segment  [Li,L2\  may  have  multiple  segments 
with  different  speed  requirements  on  C2.  Let’s  assume 
there  are  m  segments  and  let  Vu ,  1  <  i  <  m .be  the 
speed  on  segment  i.  Since  time  spend  on  both  C\  and 
C2  must  be  equal  for  each  segment,  we  have 


Vu  =  _N_ 

/3|e2| 


(a)  (b) 

Fig.  10.  Example 


Figure  10(a)  follows  a  complete  edge  of  C2  and  Fig¬ 
ure  10(b)  follows  a  complete  edge  of  Ci.  Let  corresponding 
edges  on  curves  C\  and  C2  be  ei  and  e2  with  lengths  |ei|  and 
|e2|  respectively.  Let  the  left  and  right  endpoints  of  solution  in 
current  cell  be  L\  =  (cci ,  z/i )  and  L2  =  (a ’-2,1/2)  respectively. 

•  Case  1:  Current  cell  of  free  space  diagram  follows 
a  complete  edge  of  C2  as  in  left  side  of  figure.  Let 
fraction  of  e\  in  current  cell  be  a. 

Line  segment  [Li,L2]  may  have  multiple  segments 
with  different  speed  requirements  on  C\.  Let’s  assume 
there  are  m  segments  and  let  Vu ,  1  <  i  <  m  be  the 
speed  on  segment  i.  Since  time  spend  on  both  C\  and 
C2  must  be  equal  for  each  segment,  we  have 


So,  speed  on  C2  for  a  line  segment  with  speed  Vu  on 
Ci  is 


V2l 


Vu 


M 


□ 

We  use  the  following  terminology  for  multiple  curves. 
Given  k  curves  G\, . . . ,  G\  and  a  pairwise  solution  curves 
Sji+1  is  a  solution  curve  for  curve  Ci  and  Cj+ 1  and  free 
space  diagram  FSDfi+1  is  the  free  space  diagram  for  curves 
Ci  and  Ci+i. 

Theorem  2.  Given  k  curves  Ci, ... ,  Ck  and  pairwise  solu¬ 
tion  cur\’es  SI  i+1 ,1  <  i  <  k  —  1  in  free  space  diagram 
FSD\  i+1, 1  <  i  <  k  —  1,  we  can  follow  all  solution  curi’es 
SU+i,  1  <  i  <  k  —  1  simultaneously. 

Proof:  By  repeated  application  of  Theorem  1.  Follow 
solution  curve  S^i+1  by  setting  the  speed  on  curve  Ci+i 
relative  to  the  speed  on  curve  Ci.  □ 

Depending  on  the  pattern  of  the  robot  paths,  some  heuris¬ 
tics  can  be  applied.  However,  these  heuristics  do  not  yield  the 
optimal  solution.  For  instance,  plane  sweep  solution  would  fail 
in  the  following  example.  Consider  Figure  11. 


Vu  _  a \ei\ 
V2  i  \e2\ 


Plane  sweep  in  this  example  yields  a  distance  of  4.  How¬ 
ever,  Frechet  distance  in  this  case  is  2v/2. 


Fig.  11.  Example 

V.  Simulations 

We  conducted  simulations  to  support  the  proposed  method 
both  in  terms  of  theory  and  practice  to  verify  if  multiple  robots 
can  have  connectivity  in  a  wireless  network.  We  implemented 
the  simulation  using  ns2  network  simulator  [26].  802.15.4 
MAC  layer  is  used  for  low-rate  wireless  communications. 
In  addition  to  the  simulation  results  presented  in  this  paper, 
supplementary  videos  created  from  the  simulations  can  be 
found  on  the  project  web  page  [27], 

n  random  polygonal  curves  covering  an  area  of  1000  x  1000 
are  created  for  n  robots.  The  curves  are  generated  so  that  they 
do  not  intersect.  Robot  Ri  follows  curve  c,.  The  x-coordinate 
of  any  vertices  of  Ci  is  less  than  the  x-coordinate  of  any  vertices 
of  c,_|_ i.  Simulations  with  up  to  20  robots  are  conducted.  To 
test  the  connectivity,  we  kept  track  of  the  number  of  packets 
sent  and  received  between  consecutive  robots.  The  robots  send 
dummy  packets  to  their  neighbors  with  a  frequency  of  f  which 
is  set  to  1.0s.  To  mitigate  collisions,  we  added  a  back-off 
mechanism.  For  Ri,  a  duration  of  *  i  is  added  to  the  time 
Ri  sends  its  packet.  Let  Dp(c,,  c,+  i  )  be  the  Frechet  distance 
between  curves  Ci  and  c:,+1 .  The  transmission  range  of  a 
robot,  Ri,  is  set  to  max(Di?(ci_i,  c,),  Dp(ci,  Ci+i))+A  where 
A  =  10m. 

The  type  of  a  simulation  where  the  solution  curve  between 
the  robots  Ri  and  R2  is  used  as  Sbase  is  called  simfirst.  Also, 
the  type  of  a  simulation  where  the  solution  curve  between 
the  robots  R ™  and  R%+ 1  is  used  as  Sbase  is  called  simmid- 
In  the  second  approach  to  find  the  solution  points,  we  use 
each  solution  curve  as  Sbase  and  combine  all  resulting  solution 
points.  We  call  this  type  of  simulations  simau.  We  study  both 
the  theoretical  and  the  practical  versions. 

A.  Continuous  Connectivity 

This  section  simulates  the  theoretical  solution.  One  of  the 
solution  curves  is  picked  as  the  base  solution  curve  Sbase  = 
SL  2y  Sy  is  the  solution  curve  between  the  first  and  the 
second  robot.  Solution  points  for  the  first  robot  is  selected  by 
intersecting  ST,  2,  with  the  free  space  diagram  grid  (FSDG). 
FSDG  is  defined  as  the  horizontal  segments: 

hlo[(0, 0);  (N,  0)],  Mi[(0, 1);  (N,  1)], . . . ,  hlM[( 0,  M);  (JV,  M)\ 

and  the  vertical  segments: 

vlo[(0, 0);  (0,  M)\,vh[(  1, 0);  (1,  M)\, . . . ,  vlN[(N,  0);  (N,  M)\ 

on  the  free  space  curve  where  N  is  the  curve  size  of  ci  and 
M  is  the  curve  size  of  C2.  A  segment  is  represented  as  the 
xy-coordinates  on  the  free  space  diagram.  Once  we  find  the 
solution  points  for  S'^j  2),  we  find  the  corresponding  solution 
points  on  the  rest  of  the  solution  curves.  The  solution  points 
found  on  5^  2j  is  converted  to  the  locations  on  the  curve,  ci. 


We  set  a  constant  speed,  Speed1;  for  Ri  which  follows  c\. 
Using  Speed, ,  the  associated  time  values,  tp,  are  found  for  all 
the  solution  points.  In  this  way,  all  curves  have  to  adapt  their 
speed  to  reside  at  the  corresponding  solution  points  at  the  same 
time  based  on  Ri’s  speed.  For  example,  while  R\  is  moving 
at  constant  speed,  R2  has  to  adapt  its  speed  at  the  solution 
points  based  on  .S'f,  2  j .  R2  moves  at  constant  speed  between  the 
solution  points.  For  C2,  there  exists  additional  solution  points 
from  the  intersection  of  the  solution  curve  between  C2  and  C3; 
and  FSDG  of  free  space  diagram  of  C2  and  C3.  The  timing 
values  for  these  additional  points  are  found  based  on  i?2’s 
speed  and  they  are  used  as  speed  change  locations  for  R3.  For 
the  rest  of  the  robots,  the  same  idea  is  used  causing  additional 
speed  change  locations  for  each  robot. 

In  Figure  12,  we  see  a  snapshot  taken  from  a  simulation 
using  the  theoretical  approach  where  there  are  five  robots,  and 
the  outer  robot  has  the  constant  speed  3m/s.  A  circle  represents 
the  transmission  range  of  a  robot. 


Fig.  12.  Snapshot  for  the  simulation  with  five  robots. 

When  the  theoretical  approach  is  used,  the  connectivity  is 
guaranteed  all  the  time.  Table  I  shows  the  connectivity  results 
for  the  above  example  with  5  robots  when  /  =  1.0s.  For  each 
robot,  Ri,  the  number  of  packets  R,  broadcasts,  the  number  of 
packets  received  from  the  previous  robot  Ri-i,  and  the  number 
of  packets  received  from  the  next  robot  Ri+i  is  shown  as  a 
row  in  the  table. 


TABLE  I.  Robot  Connectivity  Results  (Theory) 


Ri 

Sent 

Received  from  Ri  —  i 

Received  from  Ri+i 

Ri 

348 

- 

348 

R2 

348 

348 

348 

Rs 

348 

348 

348 

f?4 

348 

348 

347 

k5 

347 

348 

- 

Figure  13(a)  demonstrates  the  number  of  speed  change  per 
robot  when  Ri  moves  at  constant  speed  3m/s  for  20  robots. 
The  last  robot  has  to  change  its  speed  275  times. 

We  also  analyzed  the  maximum  speed  a  robot  can  take 
for  the  same  setting.  Figure  13(b)  shows  the  maximum  speed 
each  robot  takes.  To  guarantee  the  continuous  connectivity  a 
robot  should  travel  with  the  speed  of  1753m/s.  Since  this  is  not 
applicable  with  the  current  technology,  we  propose  a  practical 
approach  by  setting  a  maximum  speed  a  robot  can  take. 


Number  of  speed  changes  per  robot 


Robot  Connectivity  Results  For  1 0  Robots 


Maximum  speed  per  robot 
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Fig.  13.  Based  on  theory.  R  i  has  constant  speed  3m/s. 


TABLE  II. 


Ri 

Sent 

Received  from  Ri  —  i 

Received  from  Ri+ 1 

Ri 

376 

- 

376 

R2 

376 

375 

376 

r3 

376 

376 

376 

i?4 

376 

376 

376 

Rs 

376 

376 

370 

376 

372 

376 

Rt 

376 

376 

375 

375 

376 

375 

Rs 

375 

375 

375 

Rio 

375 

375 

- 

B.  Connectivity  at  Selected  Points 

Since  the  maximum  speed  a  robot  takes  is  not  applicable 
in  the  theoretical  approach,  we  set  a  limit  on  the  speed  a  robot 
can  take  for  practical  reasons.  In  this  approach,  connectivity 
is  guaranteed  at  selected  points.  The  solution  points  where 
connectivity  is  guaranteed  are  found  as  follows.  In  the  first 
approach,  one  of  the  solution  curves  is  picked  as  the  base 
solution  curve  Slase.  On  this  solution  curve,  the  points  on 
every  A  distance  are  chosen  as  the  solution  points.  A  values 
we  use  are  0.4,  0.2,  0.1  and  0.05.  The  corresponding  solutions 
points  on  the  rest  of  the  solution  curves  are  found  using 
these  solution  points.  Detailed  discussion  about  finding  the 
corresponding  solution  points  of  the  other  solution  curves 
based  on  one  solution  curve  can  be  found  in  subsection  III-B. 


The  speeds  of  the  robots  are  arranged  as  follows.  Let’s 
assume  that  all  robots  reside  at  their  current  solution  points 
at  time  tk .  For  example,  Ri  resides  at  L(j. iittk)  at  time  tk ■ 
Each  robot  knows  the  location  (L(/ji,tfc+1))  to  be  at  time  tk+i 
to  have  connectivity  at  tk+i-  Simulation  takes  an  argument, 
maxSpeed,  which  specifies  the  maximum  speed  a  robot  can 
travel  with.  The  robot  which  needs  to  travel  farthest  to  its 
next  solution  point  will  adjust  its  speed  to  maxSpeed.  The 
maximum  distance  to  next  solution  point  is  found  as: 

maxDistancek  =  max  || L(Ri,t  )  -  || 


Let’s  assume  that  ath  robot  needs  to  travel  farthest  to  its  next 
solution  point.  Then,  the  speed  of  Ra  is  set  to  maxSpeed. 
Once,  the  speed  of  Ra  is  found,  tk+i  is  computed;  and  the 
speeds  of  the  rest  of  the  robots  (Ri  where  1  <  i  <  n  and 
i  £  a )  are  adjusted  using  tk,  4+ 1  and  ||P(fli,tfe+1)-£(fli,tfc)ll- 
So  the  speed  of  the  robot  Ri  is  set  to: 


Si  = 


4+i  4 


Figure  14  demonstrates  a  few  snapshots  from  a  simulation  run 
of  type  sim first  with  20  robots,  /  =  1.0s,  and  maxSpeed  = 
10.  A  circle  represents  the  transmission  range  of  a  robot.  The 
simulation  takes  452s,  and  the  snapshots  are  taken  at  seconds 
150  and  300  respectively. 


Table  II  presents  the  connectivity  results  for  ten  robots 
when  /  =  1.0s,  maxSpeed  =  lOm/s  and  the  type  of  the 
simulation  is  simfirst-  Almost  all  of  the  packets  a  robot  sends 
will  be  received  by  the  neighboring  robots,  and  a  robot  receives 
almost  all  of  the  packets  the  neighboring  robots  broadcast. 
Some  robots  can  not  receive  all  the  packets  a  neighboring 
robot  sends  (see  the  communication  between  R$  and  Rq  in 
the  table).  Although  the  robots  are  guaranteed  to  be  connected 


at  the  solution  points,  we  do  not  guarantee  that  whether  a 
robot  broadcasts  at  the  solution  points  since  a  robot  broadcasts 
dummy  packets  with  a  frequency  of  1.0s  in  our  simulation. 
However,  even  in  this  case,  only  a  few  packets  are  missing 
which  shows  that  the  network  is  connected  almost  all  the  time. 
Figure  15  shows  a  case  where  the  connectivity  is  lost.  Rp  is 
guaranteed  to  be  connected  with  Rq  at  consecutive  locations 
(Pi,  Q i)  and  (P2,  Q^)-  However,  there  is  no  locations  that 
guarantee  connectivity  in  between  |Pi,  P2I  and  \Qi,Q2\-  As  a 
result,  connectivity  is  lost. 


Fig.  15.  Not  connected 


TABLE  m.  Robot  Connectivity  Results  For  5  Robots 


Ri 

Sent 

Received  from  Ri  —  i 

Received  from  Ri+i 

Ri 

345 

- 

345 

R2 

345 

345 

345 

Rs 

345 

345 

344 

i?4 

344 

345 

339 

Rs 

344 

338 

- 

Table  III  shows  the  results  for  five  robots  where  A  =  0.4. 
Moreover,  Table  IV  shows  the  results  for  five  robots  where 
A  =  0.4  on  curves  which  are  more  skewed  and  consist  of  more 
segments.  Table  V  shows  the  results  for  five  robots  following 
the  same  type  of  curves  where  A  =  0.05.  All  of  them  are 
results  from  type  simfirst  simulation. 

TABLE  IV.  Robot  Connectivity  Results  For  5  Robots 


Ri 

Sent 

Received  from  Ri— i 

Received  from  Ri+i 

Ri 

492 

- 

491 

r2 

491 

492 

487 

Rs 

491 

485 

490 

Ri 

491 

479 

All 

Rs 

491 

479 

- 

Figure  16  shows  the  number  of  changes  in  speed  per 
robot  when  the  solution  points  are  selected  based  on  the 
curves’  segment  end  points,  x-axis  denotes  the  robots  and  y- 
axis  denotes  the  number  of  changes  in  speed.  Figure  16(a) 
compares  the  simulation  types  simfirst  and  simmid.  In  this 
approach,  Rbase  has  the  most  number  of  speed  changes  since 


(a)  t  =  150  (b)  t  =  300 


Fig.  14.  Snapshots  from  our  simulation.  20  robots 


Fig.  16. 


Number  of  speed  changes  per  robot  Number  of  speed  changes  per  robot 


(a)  First  and  middle  robot. 

Comparison  of  the  settings  with  respect  to  number  of  speed  changes. 


(b)  Comparison  of  all  settings. 


TABLE  V.  Robot  Connectivity  Results  For  5  Robots 


Ri 

Sent 

Received  from  Ri  —  i 

Received  from  Ri+i 

Ri 

505 

- 

504 

R2 

504 

505 

504 

Rs 

504 

504 

501 

Ri 

504 

498 

491 

Rs 

504 

492 

- 

the  vertical  and  horizontal  lines  on  the  rest  of  the  solution 
curves  cause  solution  point  losses.  Figure  16(b)  compares  all 
of  the  simulation  types  simfirst,  simmid  and  simau.  Since 
there  exist  more  solution  points  in  simaii  type,  the  speed  of 
a  robot  needs  to  be  adjusted  many  more  times  compared  to 
the  simulation  types,  simfirst  and  simmid .  Finally,  the  total 
numbers  of  changes  in  speed  for  simfirst,  simmid  and  simau 
are  1142,  1509,  and  15460  respectively. 

VI.  Discussion 

It  is  easy  to  develop  heuristics  based  on  the  movement 
pattern  of  the  robots  for  an  application.  If  robots  are  moving  in 
one  direction,  plane  sweep  heuristic  can  be  used.  However,  this 
approach  can  not  be  generalized.  For  example,  Figure  17  shows 
a  case  where  plane-sweep  heuristic  can  not  be  used.  Also, 
even  if  the  robots  move  in  one  direction,  plane  sweep  heuristic 
does  not  yield  the  optimum  solution  in  terms  of  transmission 
range.  Figure  18  compares  the  transmission  ranges  for  Frechet 
distance  and  plane  sweep  when  the  robots  are  moving  in  one 
direction.  Frechet  distance  solution  serves  as  a  general  solution 
to  the  problem  of  connectivity  among  robots  for  any  kind  of 
path  pattern  given. 

We  focused  on  paths  which  do  not  cross  in  this  paper. 
However,  proposed  idea  can  be  applied  to  crossing  paths 
with  a  modification.  The  paths  can  be  split  at  the  crossing 
points  and  proposed  idea  can  be  used  for  partial  curves  with 
different  order  of  curves  on  each  side  of  crossing  point. 
Figure  19  demonstrates  the  idea.  At  point,  C,  the  curves  Q 
and  R  intersect.  Curves  are  split  by  the  dashed  line.  The 


Fig.  17.  Frechet  as  a  general  solution 


Frechet  distance  vs.  Sweepline 


Fig.  18.  Frechet  Distance  vs.  Sweepline 


solution  points  for  the  curves  below  the  dashed  line  and  the 
solution  points  for  the  curves  above  the  dashed  line  are  found 
separately  using  the  proposed  idea.  Below  the  dashed  line  we 
have  solution  points  corresponding  to  P  and  Q  and  Q  and  R. 
Although  same  order  of  curves  can  be  used  above  the  crossing 
point,  distances  will  end  of  being  large.  Instead  we  can  use 
solution  points  corresponding  to  P  and  R  and  R  and  Q  above 
the  dashed  line. 

In  proposed  approach,  we  set  the  transmission  range  of 
a  robot  based  on  the  Frechet  distance  and  use  the  same 
range  during  the  traversal  of  the  path.  Since  the  paths  are 


Fig.  19.  Crossing  paths 

pre-determined,  the  transmission  range  of  the  robots  can  be 
adjusted  dynamically  to  save  energy  and  reduce  interference. 
Robot  can  compute  the  range  it  needs  to  have  to  reach  the 
other  robots  and  use  this  range  for  communication. 

VII.  Conclusion 

Mobile  robots  are  introduced  to  overcome  the  limitations 
of  wireless  sensor  networks.  When  multiple  robots  are  used, 
maintaining  connectivity  between  mobile  robots  is  challeng¬ 
ing.  We  propose  a  method  to  guarantee  connectivity  among 
multiple  robots  which  move  in  a  coordinated  manner.  Having 
continuously  connected  robots  is  important  since  it  improves 
the  efficiency  and  scalability  of  network  protocols.  In  addition, 
larger  area  can  be  monitored  at  a  time  and  the  network 
becomes  more  responsive  to  attacks  and  events  when  contin¬ 
uous  connectivity  is  achieved.  We  extend  the  idea  of  Frechet 
distance  between  two  curves  to  compute  the  Frechet  distance 
between  several  curves  and  provide  a  practical  implementation 
of  the  approach.  We  provide  a  theoretical  analysis  of  Frechet 
distance  to  form  the  foundations  of  our  approach.  We  simulate 
the  proposed  method  and  verify  the  connectivity  among  the 
robots  using  our  method.  Proposed  approach  is  generic  and 
can  be  applied  to  a  large  number  of  robot  movement  patterns. 
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ABSTRACT 

Mobility  facilitates  efficient  data  collection  protocols  im¬ 
proving  the  performance,  scalability  and  life-time  of  wireless 
sensor  networks.  We  propose  a  simple,  yet  effective  and  scal¬ 
able  method  for  resilient  data  collection  in  mobile-assisted 
wireless  sensor  networks.  The  mobile  element  covers  an  area 
using  periodic  long-range  broadcast  messages.  Upon  receiv¬ 
ing  a  broadcast  message,  a  sensor  sends  its  data  to  the  mo¬ 
bile  element  using  trajectory  routing  in  a  multi-hop  manner. 
The  mobile  element  includes  sensor  acknowledgements  in  the 
broadcast  using  a  Bloom  filter.  If  a  packet  is  not  received 
by  the  mobile  element  due  to  an  erroneous  node  along  the 
trajectory,  a  different  trajectory  is  used  to  avoid  malicious 
nodes.  Simulation  results  demonstrate  that  low  number  of 
broadcasts  is  enough  to  collect  data  from  a  large-scale  net¬ 
work  with  over  99%  success  rate  if  the  system  parameters 
are  set  properly. 

1.  INTRODUCTION 

To  improve  the  scalability  and  performance  of  WSNs,  there 
has  been  a  flurry  of  work  on  employing  a  mobile  node  for 
data  collection.  The  data  mules  [12]  work  exploit  random 
movement  of  mobile  node  to  opportunistically  collect  data 
from  a  sparse  WSN.  Here,  the  nodes  buffer  all  their  data 
locally,  and  upload  the  data  only  when  the  mobile  node  ar¬ 
rives  within  direct  communication  distance.  Zebranet  [4] 
system  uses  tracking  collars  carried  by  animals  for  wildlife 
tracking.  Data  is  forwarded  in  a  peer-to-peer  manner  and 
redundant  copies  are  stored  in  other  nodes.  Shared  wire¬ 
less  info-station  model  [13]  uses  radio  tagged  whales  as  part 
of  a  biological  information  acquisition  system.  Mobility  of 
the  mobile  node  is  not  controlled  in  these  approaches.  Mo¬ 
bile  element  scheduling  (MES)  work  [14]  considers  controlled 
mobility  of  the  mobile  node  in  order  to  reduce  latency  and 
serve  the  varying  data-rates  in  the  WSNs  effectively. 

WSNs  are  vulnerable  to  various  attacks  due  to  their  na¬ 
ture.  In  selective  forwarding,  a  sensor  on  the  path  from  the 
source  to  the  destination  drops  forwarding  packets  [5] .  Pro¬ 


posed  solutions  for  detection  of  the  attack  include  watchdog 
mechanisms  where  a  node  keeps  track  of  its  neighbors’  be¬ 
havior  [8].  However,  this  solution  depletes  sensors’  resources 
quickly.  Another  scheme  which  uses  acknowledgement  from 
intermediate  nodes  is  proposed  in  [16].  False  forwarding, 
where  a  node  does  not  follow  the  forwarding  mechanism 
precisely,  is  a  type  of  misrouting  attack.  A  malicious  node 
falsify  the  routing  packets  to  disrupt  the  routing  tables  [6]. 
In  the  wormhole  attack,  an  adversary  tunnels  messages  re¬ 
ceived  in  one  part  of  the  network  over  a  low-latency  link 
and  replays  them  in  a  different  part.  An  adversary  could 
convince  nodes  who  would  normally  be  multiple  hops  from 
a  base  station  that  they  are  only  one  or  two  hops  away  via 
the  wormhole  [5].  To  defend  against  wormhole  attacks,  a 
leash  is  added  to  a  packet  to  restrict  the  packet’s  maximum 
allowed  transmission  distance  [3]. 

The  main  components  of  our  data  collection  protocol  include 
trajectory  routing,  a  cone-based  topology  control  mecha¬ 
nism,  and  Bloom  filter.  Trajectory-based  routing  (TBR)  de¬ 
scribed  in  [10,  9]  is  a  generalization  of  source  based  routing, 
and  cartesian  routing.  In  TBR,  a  packet  is  forwarded  along 
a  curve  set  by  the  source.  A  cone-based  distributed  topol¬ 
ogy  control  mechanism  proposed  in  [7]  preserves  the  network 
connectivity  by  ensuring  at  least  one  neighbor  exists  in  every 
cone  of  degree  a  around  each  sensor.  Bloom  filter  is  a  space- 
efficient  randomized  hash-coding  method  for  representing  a 
set  to  support  membership  queries  introduced  by  Burton 
Bloom  [1].  These  components  fit  together  in  harmony  pro¬ 
ducing  a  scalable  and  efficient  data  collection  mechanism. 

We  propose  a  data  collection  mechanism  resilient  to  the  node 
failures  or  packet  dropping  attacks  for  large-scale  mobile- 
assisted  wireless  sensor  networks.  The  WSN  we  consider 
consists  of  a  mobile  element  (ME)  and  static  sensors.  The 
ME  covers  the  area  to  be  monitored  using  a  pre-determined 
route.  Since  an  ME  is  expected  to  have  more  resources  than 
a  regular  sensor,  its  transmission  range  can  be  longer  than 
a  sensor’s.  On  its  journey,  the  ME  broadcasts  long-range 
messages.  Each  broadcast  message  triggers  the  sensors  in 
the  vicinity  of  the  ME  to  reply  back  with  their  data  in  a 
multi-hop  manner  using  trajectory  routing.  The  cone-based 
topology  control  mechanism  is  employed  to  control  the  num¬ 
ber  of  hops  a  packet  travels  towards  the  ME.  Bloom  filter 
is  the  main  data  structure  of  our  system’s  acknowledgement 
mechanism.  Simulation  results  indicate  the  ME  is  able  to 
collect  data  from  over  99%  of  the  total  sensors  using  the 
proposed  scheme. 


2.  SYSTEM  MODEL 

The  WSN  in  this  work  consists  of  an  ME  and  n  sensors  ( Si  is 
a  sensor  where  i  is  the  id  of  the  sensor  and  1  <  i  <  n).  The 
sensors  are  statically  deployed  in  a  bounded  region  of  A  x  A. 
We  assign  the  transmission  range  of  a  sensor  according  to 
the  distances  between  the  sensor  and  its  close  neighbors  with 
a  cone-based  topology  control  mechanism.  This  approach 
reduces  the  transmission  interference  which  is  a  bottleneck 
for  the  performance  of  an  application  designed  for  a  dense 
WSN.  Also,  it  extends  the  life-time  of  the  sensors.  r;  is  the 
range  of  the  sensor  with  the  id  i;  whereas  tme  is  the  range 
of  the  ME.  The  range  of  the  ME  is  the  same  throughout 
the  application  except  for  a  few  initial  transmissions.  Also, 
It  is  greater  than  the  range  of  any  sensors.  The  ME  covers 
the  area  of  interest  with  periodic  broadcasts,  and  speed, 
Vm e  ■  Each  broadcast  message  is  associated  with  a  sequence 
number  (SN^:  ith  sequence  number).  Sensors  within  the 
transmission  range  of  a  broadcast  reply  back  to  the  ME  with 
their  data  in  a  multi-hop  manner.  The  ME  follows  a  space¬ 
filling  curve  as  its  route.  Once  the  ME  completes  its  tour, 
it  reports  all  the  sensor  readings  it  has  collected  to  the  base 
station  (BS). 

The  communication  from  the  sensors  to  the  ME  is  based 
on  trajectory  routing.  Trajectory  routing  requires  a  dense 
network,  and  the  nodes  know  the  locations  of  their  neigh¬ 
bors,  at  least  approximately.  Therefore,  the  sensors  are  as¬ 
sumed  to  know  their  locations  and  the  locations  of  their 
neighbors.  Also,  the  ME  knows  the  sensor  locations  ap¬ 
proximately.  These  can  be  achieved  using  mobile-assisted 
localization  techniques  such  as  the  one  proposed  in  [11],  or 
an  expensive  option  for  localization  would  be  attaching  a 
GPS  device  for  each  node.  In  Trajectory  routing,  the  source 
node  embeds  a  curve  into  the  packet,  and  the  intermediate 
nodes  forward  the  packet  as  close  as  possible  to  the  curve 
using  greedy  techniques. 

The  system  model  is  shown  in  Figure  1.  The  ME  collects 
data  from  the  static  sensors  deployed  in  an  area  of  interest. 
The  circles  represent  the  sensors.  The  thick  dashed  line  rep¬ 
resents  the  route  of  the  ME.  The  transmission  range  of  the 


ME  is  larger  than  the  transmission  range  of  a  sensor.  The 
transmission  range  of  a  sensor  (Sr),  and  the  ME  is  depicted 
in  the  figure.  The  ME  transmits  long-range  broadcasts.  The 
broadcast  message  triggers  the  sensors  within  the  broadcast 
range  to  send  their  data.  An  acknowledgement  mechanism 
bypasses  unnecessary  replies.  For  example,  when  the  sensor, 
S,  receives  the  broadcast  message,  it  sends  its  data  along  the 
curve  as  shown  in  the  figure  if  S  has  not  received  its  acknowl¬ 
edgement  yet.  The  intermediate  nodes  forward  the  packet 
originated  from  S  to  the  ME  along  the  trajectory  shown  as 
the  dashed  line. 

3.  PROPOSED  SCHEME 

The  ME  covers  the  area  to  be  monitored  following  a  space¬ 
filling  curve.  It  transmits  broadcast  messages.  A  broad¬ 
cast  message  has  two  functionalities.  It  triggers  the  sen¬ 
sors  within  the  vicinity  of  the  ME  to  reply  back  with  their 
data,  and  it  contains  a  Bloom  filter  carrying  the  acknowl¬ 
edgements  for  the  sensors  whose  data  have  been  successfully 
received  after  the  previous  broadcast.  Trajectory  routing  is 
used  when  the  sensors  send  their  data  to  the  ME.  Colli¬ 
sions  are  mitigated  using  the  acknowledgement  mechanism, 
the  cone-based  topology  control  algorithm,  and  a  back-off 
mechanism  which  adds  proper  delays  to  the  reply  messages 
from  the  sensors  to  the  ME.  The  communications  are  se¬ 
cured  using  symmetric-asymmetric  keys  and  cryptographic 
functions.  The  proposed  scheme  is  designed  for  dense  net¬ 
works,  and  it  is  resilient  to  node  failures  and  packet  dropping 
attacks. 

3.1  Sensor-ME  Communication 

Trajectory  routing  is  used  for  the  communication  from  the 
sensors  to  the  ME.  When  a  sensor  receives  a  broadcast  mes¬ 
sage,  it  either  drops  the  packet,  or  replies  back  to  the  ME 
depending  on  whether  the  sensor  had  previously  sent  its  data 
to  the  ME  successfully ,  or  not.  If  the  ME  has  not  received 
the  sensor  data  yet,  the  sensor  picks  a  trajectory  where  the 
starting  point  of  the  trajectory  is  the  sensor  location,  and 
the  final  point  of  the  trajectory  is  the  ME  position.  Then, 
the  sensor  embeds  the  trajectory  into  the  packet,  and  the 
packet  is  sent  to  the  ME  along  the  trajectory  in  a  multi-hop 
manner. 

Although  a  broad  range  of  curves  can  be  defined,  we  pick  the 
upper  or  lower  arc  of  the  major  axis  of  an  ellipse  as  the  tra¬ 
jectory.  When  a  sensor  is  ready  to  send  its  data  to  the  ME, 
it  picks  one  side  of  the  ellipse,  embeds  that  trajectory  into 
its  packet,  and  sends  the  packet.  If  it  receives  an  acknowl¬ 
edgement  at  the  next  broadcast,  the  sensor  is  done  with 
sending  its  own  data  to  the  ME;  and  drops  the  succeeding 
broadcast  messages.  However,  it  continues  to  forward  the 
packets  which  were  originated  by  the  other  sensors  if  the 
sensor  is  along  the  curve  of  those  packets.  If  the  sensor  does 
not  receive  the  corresponding  acknowledgement  at  the  next 
broadcast  due  to  node  failures,  collisions,  or  insufficient  den¬ 
sity  of  the  network,  it  picks  the  other  side  of  the  ellipse  as 
its  trajectory;  and  sends  its  data  along  this  trajectory.  This 
approach  increases  the  probability  of  the  data  packets  to  be 
received  by  the  ME.  The  major  axis  of  the  ellipse  divides 
the  plane  in  half,  and  we  guarantee  that  a  node  does  not 
forward  its  packet  if  its  only  forwarding  choice  is  a  node  on 
the  other  half  plane.  Since  the  half  planes  can  not  contain  a 
sensor  in  common,  the  hops  along  both  curves  are  different. 
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Figure  2:  Switching  between  curves 


Figure  2  shows  the  interaction  between  an  ME  and  sensor 
nodes.  In  the  figure,  circles  represent  sensor  nodes,  the  two 
arcs  (solid  and  dashed)  represent  two  different  trajectories. 
The  dashed  arc  on  the  left  shows  the  long-range  broadcast 
of  the  ME  since  the  figure  shows  a  tiny  portion  of  the  whole 
network.  The  rectangles  show  the  broadcast  and  reply  mes¬ 
sage  contents.  The  source  node,  S,  embeds  the  solid  tra¬ 
jectory  into  its  packet  and  sends  the  packet  to  the  ME  in 
a  hop-by-hop  manner.  The  packet  follows  the  trajectory, 
and  in  the  ideal  case,  the  packet  is  transmitted  to  the  ME 
through  the  sensor  nodes  a,  b,  c,  d,  e,  and  f.  If  the  ac¬ 
knowledgement  for  this  packet  is  not  received  at  the  next 
broadcast,  the  sensor,  S,  sends  its  data  along  the  dashed 
trajectory.  The  packet  is  expected  to  be  forwarded  through 
the  sensors  1,  2,  3,  4,  5,  6,  7,  8. 

An  acknowledgement  mechanism  is  required  to  prevent  a 
sensor  from  replying  to  every  broadcast  message  it  receives. 
Each  broadcast  message  has  a  Bloom  filter  containing  the 
acknowledgements  corresponding  to  successful  sensor  data 
receptions  triggered  by  the  previous  broadcast  message.  In 
this  way,  sensors  become  aware  of  their  successful  data  trans¬ 
missions.  With  the  acknowledgement  mechanism,  node  fail¬ 
ures  on  the  trajectories  can  also  be  detected.  Moreover, 
if  a  sensor  does  not  receive  its  acknowledgement  due  to  a 
node  failure  on  the  trajectory,  it  uses  a  different  trajectory 
increasing  the  resilience  to  the  node  failures.  Finally,  the 
acknowledgement  mechanism  increases  the  overall  quality 
of  the  network  bypassing  unnecessary  transmissions. 

Since  the  ME  uses  long-range  broadcast  messages,  it  is  pos¬ 
sible  that  a  sensor  receives  the  broadcast  message  multiple 
times  with  different  ME  locations.  As  a  result,  the  sen¬ 
sor  uses  a  trajectory  having  different  destination  location. 
In  this  way,  different  intermediate  nodes  are  used  for  the 
sensor-ME  communication  when  the  ME  is  at  different  re¬ 
gions  increasing  the  resilience  to  the  node  failures.  As  a 
result,  A  sensor  will  have  many  chances  to  transmit  its  data 
to  the  ME  thanks  to  the  long-range  broadcasts  and  separate 
forwarding  paths  increasing  the  resilience  to  node  failures. 

3.2  ME-Sensor  Communication 

The  ME  transmits  long-range  broadcast  messages  period¬ 
ically.  The  broadcast  period,  r,  is  an  important  factor  for 
the  performance  of  our  system.  A  significant  issue  regarding 
the  broadcast  period  is  the  limitation  on  the  packet  size  for 
WSNs.  Remember  that  we  use  an  acknowledgement  mecha¬ 
nism  to  prevent  further  replies  from  the  sensors  whose  data 
had  been  received  successfully  by  the  ME  previously.  To 
achieve  this,  the  acknowledgements  are  embedded  to  the 
broadcast  packets.  Because  of  the  packet  size  limitation, 
there  is  a  limit  on  the  number  of  the  acknowledgements 


that  can  be  embedded  into  the  broadcast  packet.  We  use 
a  probabilistic  space-efficient  data  structure,  Bloom  filter, 
to  increase  the  number  of  acknowledgements  that  can  be 
embedded  into  a  broadcast  message. 

Bloom  filter  is  used  to  test  whether  an  element  is  a  mem¬ 
ber  of  a  set  or  not.  It  is  a  one-bit  vector  array  of  size  m, 
initially  all  bits  set  to  0.  Whenever  an  element  is  inserted 
to  the  Bloom  filter,  the  element  is  first  hashed  by  k  inde¬ 
pendent  and  uniformly  distributed  hash  functions.  Each  of 
the  k  hash  values  is  used  as  the  bit  index  of  the  Bloom  filter 
which  is  set  to  1.  In  our  protocol,  when  the  ME  receives 
a  packet  originating  from  a  sensor,  Si,  with  the  sequence 
number  SNj,  the  ME  applies  the  one-way  shal  function  on 
idsJSNj.  The  Bloom  filter  is  reset  for  each  broadcast  mes¬ 
sage.  shal  produces  a  20  byte  message  digest  of  which  we 
use  each  of  the  first  k  bytes  as  the  index  values  to  the  Bloom 
filter.  This  is  repeated  for  all  the  sensors  which  can  trans¬ 
mit  their  data  successfully  to  the  ME.  The  Bloom  filter  is 
included  in  the  next  broadcast  message  (SNj+i).  When  the 
sensor,  s;,  receives  the  broadcast,  it  queries  the  Bloom  filter 
using  the  result  of  shal  applied  on  idSi|SNj.  The  sensor  ei¬ 
ther  drops  the  broadcast  or  replies  back  to  the  ME  depend¬ 
ing  on  the  membership  in  the  Bloom  filter.  If  the  sensor 
does  not  see  its  id  in  the  Bloom  filter,  it  replies  with  its 
data.  In  the  meantime,  the  ME  resets  the  Bloom  filter  for 
the  new  broadcast,  and  inserts  the  acknowledgement  for  the 
sensors  from  which  the  ME  received  their  data.  The  bloom 
filter  containing  the  acknowledgement  corresponding  to  the 
broadcast  message  with  SNj+i  is  included  in  the  new  broad¬ 
cast  message  with  SNj+2-  The  same  mechanism  is  repeated 
for  all  broadcasts.  In  this  way,  a  sensor  knows  whether  the 
sensor  data  is  received  by  the  ME  or  not. 
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Figure  3:  Data  collection  protocol. 

The  false  positives  rate  ( fpr )  of  a  Bloom  filter  can  be  con¬ 
trolled  through  the  parameters  nbf,  m ,  and  k ;  since  the  fpr 
_  , 

is  approximately  (1  — e-™- )  .  Because  of  the  packet  size  lim¬ 
itation  in  WSNs,  we  pick  m  as  256  bits  (32  bytes).  More¬ 
over,  we  only  let  1%  or  less  than  1%  of  fpr.  Under  these 
constraints,  nbf  is  found  as  25,  and  k  is  found  as  5  after 
trying  various  values  for  nbf  and  k  for  our  data  collection 
application.  As  a  result,  our  Bloom  filter  is  capable  of  hold¬ 
ing  nbf  acknowledgements  for  nbf  sensors  at  each  broadcast 
message,  nbf,  the  number  of  total  sensors  in  the  network 
(n),  the  speed  ( vme )  and  the  range  of  the  ME  (tme)  are 
the  key  factors  for  determining  the  broadcast  period.  As¬ 
suming  most  of  the  sensors  within  the  range  of  the  previous 
broadcast  message  are  acknowledged,  the  next  broadcast  is 
transmitted  when  there  are  nbf  expected  unacknowledged 
sensors  within  the  range  of  the  ME.  In  Figure  3(a),  the  solid 
circles  represent  the  sensors  which  have  received  their  ac- 


knowledgements  from  the  ME;  and  the  void  circles  represent 
the  sensors  which  could  not  receive  their  acknowledgements 
yet.  The  figure  shows  two  consecutive  broadcasts.  Since  the 
Bloom  filter  is  able  to  carry  ribf  sensor  acknowledgements, 
the  next  broadcast  is  transmitted  when  the  shaded  area  in 
the  figure  holds  ribf  expected  number  of  sensors.  Let  the 
shaded  area  be  As.  Then,  As  =  —  d2  where  A2  is  the  to- 
tal  area  of  the  monitored  field.  As  is  actually  the  difference 
of  the  two  circles  with  radius  vme-  A3  =  Csn1+1  — 
where  CsNi  is  the  transmission  area  of  the  broadcast  mes¬ 
sage  with  SNi,  and  CsNi+1  is  the  transmission  area  of  the 
consecutive  broadcast  message.  From  geometry,  we  know 
that  the  area  of  the  difference  of  any  two  circles  with  the 

same  radius  is  Circdifr  =  Er2ME  -  2(gr“E  -  f  \jr2ME  -  (|)2) 
where  0  =  2  arccos(2T,^E )  is  the  angle  of  the  arc  between 
the  intersection  points  of  the  two  circles,  and  d  is  the  dis¬ 
tance  between  the  two  circles.  If  As - Circdifr,  then  the 

centers  of  the  circles  are  the  locations  of  two  consecutive 
broadcast  messages.  Let  dc  be  the  d  value  guaranteeing  the 
equality,  As  ==  Circdiff-  dc  becomes  the  expected  distance 
between  two  consecutive  broadcast  messages.  Since  all  the 
variables  other  than  d  is  known,  dc  is  computed  using  a 
binary  search.  Then,  the  expected  broadcast  period,  r,  is 
calculated  as  r  =  ,.dc  . 

3.3  Controlling  Collisions 

Upon  receiving  a  broadcast  message,  if  the  sensors  in  the 
vicinity  of  the  ME  reply  back  to  the  ME  all  at  the  same  time, 
collisions  occur  inevitably.  Therefore,  a  back-off  mechanism 
is  required  to  mitigate  the  number  of  collisions.  After  finding 
the  delay,  a  sensor  predicts  the  location  of  the  ME  at  the 
time  (current  time  +  delay)  the  sensor  will  be  sending  its 
data,  and  uses  this  location  as  the  destination  point  of  its 
trajectory. 

The  aim  of  the  back-off  mechanism  is  to  assign  different 
periods  of  delays  to  the  sensors.  After  receiving  a  broadcast 
message,  a  sensor,  Si,  calculates  a  delay  of  period  (Delay Si) 
which  is  less  than  the  broadcast  period,  r.  DelaySi  depends 
on  the  orientation  of  the  sensor  with  respect  to  the  ME, 
and  the  heading  of  the  ME.  Recall  that  two  consecutive 
broadcasts  intersect  because  of  the  limitation  on  the  packet 
size.  This  limitation  favors  the  mitigation  of  the  collisions 
since  fewer  sensors  have  to  send  their  data  within  the  period 
between  two  consecutive  broadcasts. 

The  location  of  the  ME  at  the  time  a  sensor  is  sending  its 
reply  message  needs  to  be  predicted.  The  predicted  ME 
location  is  set  as  the  destination  point  of  the  trajectory. 
The  broadcast  message  includes  the  ME  location,  and  a  few 
corners  of  the  space  filling  curve  being  used.  For  example, 
if  Hilbert  Curve  (HC)  [2]  is  used  as  the  route  of  the  ME, 
the  next  two  HC  corners  the  ME  will  visit  are  included  in 
the  broadcast.  The  speed  of  the  ME  is  also  known  by  the 
sensor  (can  be  included  in  the  broadcast  messages).  Using 
this  information  together  with  the  Delay Si,  predicting  the 
location  of  the  ME  at  the  time  Si  sends  its  reply  message 
becomes  trivial. 

4.  SIMULATIONS 

We  conducted  extensive  simulations  to  support  the  proposed 
scheme.  We  implemented  the  simulations  using  ns2  wireless 


network  simulator.  Our  protocol  is  implemented  and  added 
as  a  new  protocol  to  ns2  core  code.  We  used  a  modified 
version  of  802.11  MAC  layer.  The  RTS/CTS  mechanism 
is  disabled  to  provide  the  communication  between  two  ele¬ 
ments  which  have  different  transmission  ranges  as  our  proto¬ 
col  requires,  and  to  mimic  802. 15.  f  standards.  Disabling  the 
RTS/CTS  protocol  also  mitigates  the  collisions  since  there 
will  be  relatively  less  transmissions.  In  addition  to  the  sim¬ 
ulation  results  presented  in  this  paper,  supplementary  sim¬ 
ulation  results  can  be  found  on  the  project  web  page  [15]. 
Videos  are  available  for  some  of  the  individual  sample  runs 
of  the  simulations  to  give  an  idea  about  the  mechanics  of 
the  system. 

n  sensors  are  deployed  using  uniform  distribution  in  a  region 
of  1000m  x  1000m.  The  values  of  the  system  parameters  are 
the  following:  number  of  sensors  (n:  200,  400,  800,  1600, 
3200),  maximum  sensor  range  ( rmax :  10m,  20m,  30m,  ..., 
150m),  the  range  of  the  ME  (tme.  150m,  200m,  250m),  cone 
alpha  values  (a:  60°,  90°, 120°,  150°),  curve  levels  (2,  3), 
and  the  ME  speed  (Vme'  3m/s,  6m/s).  Also,  the  constant 
parameters  for  the  Bloom  filter  are  m  =  256,  ribf  =  25, 
and  k  =  5.  For  each  setting,  we  generated  100  different 
sensor  configurations.  Our  main  performance  criterion  is 
the  success  rate  which  is  described  as  the  percentage  rate 
of  the  number  of  the  sensors  whose  data  is  received  by  the 
ME  over  the  number  of  all  sensors  considering  that  the  ME 
tours  the  area  to  be  monitored  once. 

Although  any  space-filling  curve  can  be  used  as  the  route  of 
the  ME,  we  used  two  different  space-filling  curves  for  com¬ 
parison  purposes:  Hilbert  curve(HC),  and  snake-scan  curve 
(SC)  which  is  a  non-recursive  space-filling  curve.  A  level-3 
HC  is  shown  in  Figure  3(b).  A  HC  is  defined  recursively.  4 
level  k  curves  are  combined  to  have  a  level  k  + 1  curve  as  fol¬ 
lows.  A  square  is  initially  divided  into  4  ordered  quadrants 
and  a  first-order  curve  is  drawn  by  connecting  the  center  of 
the  quadrants.  For  the  next  level  of  HC,  each  of  the  quad¬ 
rants  is  divided  into  4  and  4  scaled-down  level  1  HCs  are 
connected  by  changing  the  level  1  HCs’  orientations  preserv¬ 
ing  their  order.  SC  produces  better  results  since  it  contains 
less  number  of  turns  compared  to  HC.  Although  the  use  of 
SC  outperforms  the  use  of  HC,  their  success  rates  are  almost 
identical.  We  focus  on  HC  for  the  route  of  the  ME  as  we 
present  the  simulation  results. 

The  required  number  of  broadcasts  is  feasible  although  the 
system  achieves  high  success  rates.  The  number  of  broadcast 
messages  depends  on  tmb,  n,  and  the  length  of  the  ME  route 
( HCievei ).  The  relation  among  these  variables  are  shown  in 
Figure  4(a)  where  HCievei  =  2  is  used.  As  n  increases,  the 
number  of  broadcasts  increases  since  the  required  area  of 
the  difference  of  two  consecutive  broadcast  messages  gets 
smaller  and  the  broadcast  frequency  increases.  Also,  the 
number  of  broadcasts  is  directly  proportional  to  vme ■  The 
broadcast  period,  t,  depends  on  vme,  n,  and  Vme-  The  re¬ 
lation  among  r,  tmb,  and  n  is  demonstrated  in  Figure  4(a) 
when  Vme  =  3.  As  tmb  increases,  r  decreases  since  the 
area  of  the  difference  of  two  consecutive  broadcast  messages 
increases  faster  when  tme  is  longer.  When  the  network  gets 
denser,  the  required  area  of  the  difference  of  two  consecu¬ 
tive  broadcast  messages  gets  smaller  since  dense  network  has 
more  sensors  per  unit  of  area;  and  r  decreases. 
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Figure  4:  Number  of  broadcasts  and  broadcast  pe¬ 
riod 


The  ranges  of  the  sensors  are  arranged  using  the  cone-based 
topology  algorithm.  The  technology  can  only  allow  limited 
number  of  range  levels  for  the  transmission  range  of  the 
commercial  sensors  [7].  In  our  simulations,  the  cone-based 
topology  mechanism  is  applied  assuming  the  sensors  are  able 
to  set  one  of  eight  range  levels  to  their  transmission  range. 
Tmax  is  divided  into  eight  and  the  result  is  set  to  range  level 
1.  The  other  range  levels  are  computed  by  adding  the  divi¬ 
sion  result  each  time  as  the  eighth  level  being  rmax. 

Most  of  the  simulation  results  we  present  discuss  the  cases 
where  the  sensor  range  is  increasing.  The  graphs  use  the 
maximum  sensor  range  (rmaa;)  as  the  sensor  values  for  clear 
representation.  However,  the  real  values  for  the  sensor  ranges 
are  different  depending  on  the  a  cone  value,  and  the  network 
density  since  we  are  deploying  the  cone-based  topology  al¬ 
gorithm.  We  use  a  =  60°,  and  120°  in  our  simulations.  To 
give  an  idea  regarding  the  relation  between  the  rmaa,  values 
and  the  average  of  real  sensor  ranges  for  different  settings, 
Figures  5(a),  and  5(b)  are  used  respectively  for  a  values 
60°,  and  120°.  The  figures  include  the  deployments  with 
800,  1600,  and  3200  sensors.  As  seen  in  the  figures,  for  low 
rmax  values,  the  averages  of  the  real  sensor  ranges  are  the 
same  as  the  rmax  values.  As  the  maximum  sensor  range  in¬ 
creases,  the  effect  of  cone-based  topology  control  algorithm 
can  be  seen  since  a  sensor  now  has  more  neighbors  around 
it.  Also,  the  average  of  the  real  sensor  range  values  for  dense 
networks  is  less  than  the  average  of  the  ones  for  scarce  net¬ 
works  because  of  the  same  reason.  Finally,  the  average  of 
the  real  sensor  ranges  when  a  =  120°  is  less  than  the  average 
of  the  real  sensor  ranges  when  a  =  60°  as  expected. 
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Figure  5:  Cone-based  topology. 


The  success  rate  of  our  system  is  promising  collecting  data 
from  over  99%  of  the  sensors  deployed.  The  success  rate 
values  as  the  maximum  sensor  range  increases  are  depicted 
in  Figure  6(a)  for  the  configuration  where  tme  =  200m, 
HCievei  =  2,  a  =  120°,  and  Vme  =  3m/s.  In  the  fig¬ 
ure,  the  x-axis  represents  the  maximum  sensor  range.  The 
actual  sensor  ranges  are  different  than  the  presented  since 


the  cone-based  topology  is  used.  For  example,  a  setting 
with  3200  sensors  achieve  the  optimum  success  rate  when 
rmax  =  40m.  The  corresponding  average  sensor  range  is 
found  to  be  about  30m  when  Figure  5(b)  is  analyzed.  In  the 
beginning,  as  the  sensor  range  increases,  the  success  rate 
also  increases.  The  reason  is  when  the  sensor  range  is  small, 
a  sensor  does  not  have  enough  neighbors  to  apply  the  trajec¬ 
tory  routing.  Also,  dense  networks  achieve  their  optimum 
success  rates  earlier  than  the  scarce  networks  because  dense 
networks  have  more  number  of  neighbors  which  results  in 
better  routing  performance. 

The  number  of  total  collisions  as  the  sensor  range  increases 
for  the  same  configuration  is  shown  in  log-scale  in  Figure  6(b). 
For  all  sensor  range  values,  more  collisions  occur  in  dense 
networks  compared  to  scarce  networks  as  expected.  In  the 
beginning,  the  sensor  range  is  small,  so  the  collisions  are  less 
likely  to  occur.  As  the  sensor  range  increases,  the  number 
of  collisions  also  increases  until  sensors  start  to  send  their 
data  to  the  ME  successfully.  When  more  packets  are  be¬ 
ing  received  by  the  ME,  the  number  of  collisions  start  to 
decrease  since  a  sensor  is  not  required  to  re-send  its  data 
once  it  receives  its  acknowledgement.  The  number  of  col¬ 
lisions  continue  decreasing  sharply  until  optimum  success 
rates  are  achieved.  Further  increase  in  sensor  range  provides 
less  collisions  since  the  number  of  hops  in  the  communica¬ 
tions  between  the  sensors  and  the  ME  will  decrease.  We  also 
analyzed  the  distribution  of  the  collisions.  The  maximum 
number  of  collisions  per  sensor  is  as  low  as  1  for  individual 
simulation  optimum  settings  with  1600  or  less  sensors.  The 
maximum  number  of  collisions  per  sensor  is  about  40  for 
the  simulations  resulting  optimum  success  rate  with  3200 
sensors.  Also,  more  packets  collide  on  the  sensors  closer  to 
the  ME  route.  When  the  ME  changes  its  direction,  more 
collisions  occur.  Furthermore,  when  the  range  of  the  ME 
increases,  the  number  of  collisions  also  increases  since  more 
sensors  are  triggered  to  send  their  replies. 


robot  range:  200,  speed:  3,  he:  2,  alpha:  120,  filter:  256|25|5 


robot  range:  200,  speed:  3,  he:  2,  alpha:  120,  filter:  256|25|5 


(a) 


(b) 


Figure  7:  Average  number  of  hops  per  packet  and 
total  no  of  false  positives. 

The  average  number  of  hops  a  packet  visits  ( Hopavr )  is 
shown  in  Figure  7(a).  As  the  sensor  range  increases,  the 
packets  are  more  likely  to  be  received  by  the  ME  and  Hopavr 
increases.  Hopavr  reaches  its  maximum  value  when  the  suc¬ 
cess  rate  is  maximum.  After  this  point,  the  increase  in  sen¬ 
sor  range  results  in  less  Hopavr  values  since  the  packet  can 
reach  the  ME  using  less  many  hops.  The  sensor  ranges  are 
shorter  when  denser  networks  are  considered  as  a  result  of 
the  cone-based  topology  algorithm.  Therefore,  Hopavr  val¬ 
ues  for  dense  networks  are  higher  than  Hopavr  values  for 
sparse  networks.  The  total  number  of  false  positives  caused 
by  the  Bloom  filter  is  depicted  in  Figure  7(b).  The  number 
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Figure  6:  Success  ratio  and  collisions. 
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of  false  positives  reaches  its  local  minimum  value  when  the 
success  rate  is  maximum.  In  terms  of  speed,  the  success  rate 
decreases  as  the  ME  travels  faster  since  the  performance  of 
the  back-off  mechanism  decreases  causing  more  collisions. 

5.  CONCLUSION 

In  this  paper,  we  propose  an  efficient,  scalable,  and  re¬ 
silient  data  collection  protocol  for  large-scale  mobile  assisted 
WSNs.  The  system  is  built  on  components  including  trajec¬ 
tory  routing,  cone-based  topology  mechanism,  and  Bloom 
filter  which  are  seamlessly  integrated.  Performance  of  the 
proposed  scheme  depends  on  many  tunable  parameters  in¬ 
cluding  sensor  range,  density  and  topology  of  the  network. 
Using  simulations,  we  show  that  the  system  parameters  can 
be  tuned  for  a  high  rate  of  successful  data  collection.  It  is 
possible  to  cover  a  large  area  using  limited  number  of  broad¬ 
casts  for  networks  with  sufficiently  high  density  ideal  for 
trajectory  routing.  Collisions  play  an  important  role  on  the 
success  rate,  and  they  are  minimized  with  a  back-off  mech¬ 
anism.  As  sensor  range  is  increased,  success  rate  initially 
increases  and  starts  to  decrease  after  reaching  its  maximum 
value.  This  is  due  to  the  higher  number  of  collisions  that 
occur  with  increased  range.  Finally,  future  work  includes 
identifying  the  misbehaving  or  malicious  nodes. 
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Abstract — Chromecast  is  a  small,  system-on-chip  device,  that 
plugs  into  the  HDMI  port  of  a  larger  screen  and  turns  it  into  a 
smart  screen.  It  is  designed  for  multimedia  streaming  in  a  home- 
network  environment.  By  setting  up  Chromecast,  you  can  stream 
videos  onto  a  larger  screen  and  control  it  from  a  mobile  device 
such  as  a  smart-phone,  tablet  or  a  laptop.  The  idea  is  to  cast  the 
multimedia  to  a  larger  second  screen  and  use  the  smaller  one  as  a 
remote  control.  Since  its  based  on  Google  Cast  SDK  which  is  open 
to  developers,  a  growing  number  of  multimedia  content  providers 
such  as  YouTube,  Netflix,  Hulu  and  HBO  are  offering  appli¬ 
cations  to  support  Chromecast  streaming  for  mobile  operating 
systems.  This  device  uses  Discovery  and  Launch  (DIAL)  protocol, 
developed  by  YouTube  and  Netflix.  We  examined  the  network 
packets  exchanged  between  the  smaller  remote  control  device 
and  the  Chromecast  attached  larger  screen.  While  Chromecast 
encrypts  most  of  the  content,  remote  control  device  sends  control 
packets  to  the  remote  servers  in  the  dear-text,  which  makes  it 
vulnerable  to  reply-attacks  or  session-hijacking  attacks.  Besides, 
data  transmission  pattern  leak  personal  information  outside  of 
the  home-network,  raising  privacy  concerns.  Network  protocols 
used  by  Chromecast  are  investigated  and  known  vulnerabilities 
are  listed.  A  method  to  detect  the  existence  of  Chromecast  behind 
a  home-router  is  proposed. 

I.  Introduction 

With  the  recent  improvements  in  networking  and  multime¬ 
dia  technology  in  the  last  couple  of  years,  streaming  high 
definition  audio  and  video,  whether  its  local  or  remote,  became 
increasingly  popular  in  a  home-network  environment.  Many 
hardware  and  software  companies  have  been  stimulating  the 
consumer  market  by  developing  innovative,  convenient,  cost 
effective  multimedia  devices  that  are  easy  to  integrate  to  a 
home-network  setting.  Apple  TV  [8],  Google  TV  [10],  Roku 
Streaming  Player  [13],  Netgear  NeoTV  [12],  and  Amazon  Fire 
TV  [7]  are  just  a  few  of  the  most  popular  devices  on  the 
market.  Apple  TV  lets  their  users  stream  1080p  HD  content 
over  the  internet  from  the  most  popular  video  providers  such  as 
Netflix,  Hulu  Plus,  YouTube,  Vimeo  and  iTunes.  It  has  AirPlay 
technology  to  stream  local  content  from  mobile  devices  such 
as  a  phone  or  tablet.  Google  TV  is  a  platform  which  is 
designed  to  combine  entertainment  from  TV,  apps,  and  the 
internet.  It  comes  integrated  into  new  smart  TVs  like  LG  Smart 
TV  as  well  as  with  set-top-boxes  such  as  NetGear  NeoTV, 
Sony  Internet  Player,  Asus  Cube  and  Vizio  Co-Star.  Roku 
is  in  the  market  with  a  Chromecast  like  streaming  HDMI 
stick  that  has  similar  hardware  and  functionality.  In  addition, 
Roku  has  set-top-boxes  Roku  1,  Roku  2  and  Roku  3  which 


are  comparable  to  Apple  TV.  Netgear  NeoMediacast  HDMI 
Dongle  [11]  is  another  HDMI  stick,  which  is  about  to  be  re¬ 
leased  to  the  market.  It  runs  Android  OS  and  is  decorated  with 
the  latest  specification  WiFi  hardware,  Miracast  functionality 
and  integrated  DRM  support.  Chromecast  is  a  cost  effective 
way  of  streaming  multimedia,  either  from  Internet  or  locally 
stored,  onto  a  larger  screen.  Its  an  HDMI  stick  that  connects  to 
HDMI  port  and  communicates  over  Wi-Fi.  Among  the  severe 
competition  in  the  market,  Chromecast  [9]  has  emerged  as  the 
most  successful  with  respect  to  functionality /cost  metric. 

In  this  paper,  we  have  evaluated  the  network  protocols  used 
by  Chromecast;  packet  flow  between  client,  Chromecast  and 
external  servers;  and  examined  the  network  communications 
in  a  blackbox  manner  from  security  and  privacy  perspective. 

The  rest  of  the  paper  is  organized  as  follows:  Section  II  dis¬ 
cusses  the  related  work.  In  Section  III,  background  information 
about  the  Chromecast  Device  and  DIAL  protocol  is  presented. 
Experimental  test-bed  setup  and  experimental  results  are  given 
in  Section  IV.  Conclusion  of  the  paper  and  future  work  plans 
about  security  of  Chromecast  is  presented  in  Section  VI. 

II.  Related  Work 

In  this  section,  the  related  work  on  security  analysis  of 
protocols  used  by  Chromecast  and  the  relevant  papers  will 
be  briefly  mentioned.  To  the  best  of  our  knowledge,  there  has 
been  no  evaluation  of  the  Chromecast  device  in  the  literature. 

Chromecast  runs  a  stripped-down  version  of  Android  OS, 
with  limited  capability  of  application  installation.  Although 
there  has  been  a  flurry  of  research  on  Android  security 
recently,  most  of  the  research  focuses  on  full-fledged  An¬ 
droid  OS  and  application  security.  More  than  1000  Android 
malware  samples  were  investigated  in  [24]  and  most  of  the 
malware  were  repackaged  versions  of  legitimate  applications 
with  malicious  payloads.  Different  approaches  were  used  to 
investigate  security  of  Android  applications.  Taintdroid  [3] 
monitors  behavior  of  Android  applications  to  detect  misuse 
of  private  information  and  Kirin  [5]  is  a  security  service 
for  lightweight  certification  to  mitigate  malware  at  install 
time.  Static  analysis  was  used  on  more  than  1,000  Android 
applications  for  security  [4]  and  widespread  misuse  of  private 
information  and  advertising  networks  is  detected.  Readers 
are  referred  to  [6]  for  an  overview  of  Android  Security 
Framework.  All  of  the  above  research  focuses  on  a  complete 


Android  OS  and  to  our  knowledge  no  work  exists  for  stripped- 
down  android  OS  used  on  Chromecast  device. 

STUN  protocol  is  used  by  Chromecast  while  a  local  com¬ 
puter  with  a  Chrome  browser  running  TabCasting  extension  to 
mirror  a  browser  tab  onto  Chromecast.  Recently,  researchers 
have  uncovered  multiple  vulnerabilities  in  Belkin  WeMo 
Home  Automation  devices,  one  of  which  was  due  to  the  way 
STUN  protocol  used  in  the  framework  [14],  According  to 
the  advisory,  using  one  Wemo  device  an  attacker  may  be  able 
to  use  the  STUN  &  TURN  protocols  to  relay  connections  to 
any  other  Wemo  device.  There  are  possible  attack  scenarios 
listed  in  the  Security  Considerations  section  of  RFC-5389  [21]. 
Attacks  against  the  STUN  protocol  include,  outside  attacks; 
where  an  attacker  modifies  the  messages  in  transit  in  order 
to  fail  the  operation  of  STUN  between  client  and  server. 
Inside  attacks  could  occur,  such  as  a  rogue  client  that  may 
try  to  launch  a  DoS  attack  against  a  server  by  sending  large 
number  of  STUN  requests.  In  security  sensitive  applications 
TLS  might  be  used  to  encrypt  the  STUN  packets,  however 
Chromecast  does  not  make  use  of  TLS  with  STUN.  To  the 
best  of  our  knowledge,  there  is  no  published  academic  paper 
in  the  literature  discussing  the  attacks  scenarios  mentioned  in 
the  RFC  in  detail. 

Network  Time  Protocol  (NTP)  is  used  by  Chromecast  to 
synchronize  its  time  after  a  reboot  or  when  connecting  to 
the  internet  after  an  extended  period  of  time.  In  [15],  authors 
discuss  the  security  issues  of  NTP  protocol.  As  a  solution 
to  address  the  security  problems  in  NTP  protocol,  authors 
proposed  a  new  security  model  named  Autokey  which  is 
implemented  in  NTP  version  4.  However,  in  our  experiments 
NTP  client  included  with  Chromecast’s  operating  system 
always  used  the  NTP  version  3,  which  has  many  known 
vulnerabilities  and  security  holes. 

Our  experiments  made  use  of  commodity  hardware  running 
on  Linux  OS,  in  order  to  capture  the  Chromecast  traffic.  The 
work  of  authors  in  [1]  provides  guidelines  for  configuring 
the  packet  capturing  system  for  optimal  performance.  Even 
though,  in  our  experiments  we  did  not  stress  the  network  with 
more  than  normal  amount  of  traffic,  the  methods  in  this  paper 
are  applied  to  improve  the  packet  capture  performance  for  the 
benefit  of  future  work  experiments  such  as  DoS  resilience  of 
Chromecast. 


III.  Background 

In  this  section  we  will  discuss  the  underlying  protocol 
Chromecast  device  and  Chromecast  enabled  apps  are  talking 
in  order  to  discover  each  other. 

A.  Discovery  and  Launch  (DIAL)  Protocol 

Netflix  and  YouTube  engineers  developed  Discovery  and 
Launch  (DIAL)  Protocol  [17]  in  cooperation.  This  open  source 
protocol  eases  the  application  development  and  integration. 

This  protocol  is  used  by  Chromecast,  for  the  purpose  of 
discovering  and  launching  applications  on  1st  screen  devices, 
by  2nd  screen  devices.  1st  screen  devices  have  smaller  screens, 
such  as  a  tablet,  mobile  phone  or  a  laptop.  Whereas,  2nd  screen 


devices  are  primarily  built  for  better  display  with  larger  screen 
sizes.  TVs,  set-top  boxes,  Blu-ray  players,  LCD  monitors 
could  be  classified  as  2nd  screen  devices. 

In  a  situation  where  one  finds  a  video  on  his/her  mobile 
phone  and  wants  to  play  it  on  a  local  connected  TV,  he 
can  launch  the  mobile  app  on  the  phone  and  then  tap  the 
Play  on  TV  button  on  the  mobile  app.  DIAL  protocol  is  the 
underlying  communication  protocol  that  enables  this  simple 
interaction  [17], 

DIAL  is  only  used  for  discovery  and  launch  of  an  appli¬ 
cation,  it  does  not  provide  further  means  of  communication 
between  2nd  and  1st  screen  apps.  DIAL  also,  does  not 
involve  nor  require  pairing  or  authentication,  since  its  a  simple 
mechanism  for  discovering  and  launching  apps  on  a  single 
subnet,  such  as  a  home  network  [17]. 

Chromecast  and  devices  on  the  same  network  with  Chrome¬ 
cast  communicates  via  DIAL  protocol  to  discover  each  other. 
Both  devices  send  multicast  SSDP  messages  over  UDP  to 
IP  address  239.255.255.250  on  port  1900.  M-SEARCH  * 
HTTP/1.1  packets  are  multicasted  by  clients  for  Chrome¬ 
cast  discovery,  while  Chromecast  device  sends  NOTIFY  * 
HTTP/1.1  packets  to  announce  the  IP  address  and  port  its 
listening  to  and  the  location  of  its  device  description  XML 
file.  According  to  NOTIFY  *  packets  sent  by  Chromecast, 
device  description  file  is  found  at  http://local-chromecast-ip- 
address:8008/ssdp/device-desc.xml.  Chromecast  runs  a  UPNP 
Server  with  a  kernel  linux/3.8.13,  over  UPnP  version  1.0  and 
it  uses  libupnpl.6.18  Portable  SDK  for  UPnP  devices.  X-User- 
Agent  field  has  redsonic  in  Chromecast  SSDP  packets. 

One  security  concern  mentioned  in  DIAL  specification 
involves  properly  dealing  with  optional  DIAL  payloads.  DIAL 
payloads  are  a  container  for  information  that  can  be  passed 
to  a  first  screen  app  via  the  DIAL  start  request  as  URL 
encoded  UTF-8  strings.  If  payloads  are  accepted,  1st  screen 
app-develeper  must  ensure  to  do  a  proper  security  analysis 
since  these  requests  could  come  from  an  untrusted  source  [17]. 

IV.  Experimental  Results 

In  this  section,  we  provide  and  discuss  the  results  of 
experiments  executed  on  the  testbed  shown  in  Figure  1. 
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Fig.  1.  Experimental  Network  Setup 


A.  Home-Network  Testbed  Setup 

In  our  experimental  test-bed  we  had;  a  Chromecast  device 
plugged  into  the  HDMI  port  of  an  LCD  monitor,  an  Android 
tablet  as  Chromecast  remote  device,  and  a  laptop  as  a  traffic 
monitoring  device  are  connected  to  a  D-Link  DIR-615  v.E3 
Wireless  Router  as  shown  in  Figure  1. 

The  router  used  in  the  experiments  was  a  D-Link  DIR- 
615rev.E3  which  is  fairly  cheap,  low-end,  targeted  for  home- 
user,  off-the  shelf  device.  Router  hardware  is  flashed  with 
open-source  Open-Wrt  [19]  firmware.  Open-Wrt  [19]  is  a 
Linux  based  alternative  OpenSource  firmware  suitable  for  a 
great  variety  of  WLAN  routers  and  embedded  systems.  We 
made  use  of  iptables  [16]  firewall  that  is  embedded  into  most 
linux  based  kernels.  Open-Wrt  kernel  comes  with  iptables 
firewall. 

Even  though  linux  kernels  include  iptables,  because  of 
memory  space  limitations,  open-wrt  excluded  the  module 
required  for  port-mirroring  functionality.  We  have  customized 
and  built  the  source  after  adding  the  support  for  iptables  kernel 
module  ipt_TEE.  With  the  ipt_TEE  support,  it  was  possible  to 
mimic  the  high-end  router  capability  called  ’’Port-Mirroring” 
with  our  low-end  router. 

By  adding  rules  to  mangle  [23]  table  of  iptables  firewall, 
to  send  a  copy  of  each  packet  destined  or  sourced  from  the 
Chromecast  device  IP,  we  were  able  to  monitor  the  network 
traffic. 

The  following  iptables  commands  are  used  to  mirror  all  of 
the  network  communication; 

$  iptables  -t  mangle  -A  POSTROUTING  -s  192.168.1.0/24  -j  TEE  — gateway  192.168.1.154 
$  iptables  -t  mangle  -A  POSTROUTING  -d  192.168.1.0/24  -j  TEE  — gateway  192.168.1.154 

The  first  firewall  rule  here,  sends  a  copy  of  all  locally 
generated  packets  to  the  gateway  machine  at  IP  address 
192.168.1.154,  which  is  running  wireshark  to  capture  the 
packets. 

Second  rule  mirrors  a  copy  of  each  packet  that  is  destined 
to  a  local  machine,  coming  from  an  outside  machine. 

In  order  to  connect  to  Chromecast,  Google’s  official 
Chromecast  app  is  installed  to  the  Android  tablet  from  Google 
PlayStore.  Additionally,  couple  of  apps  such  as  HBO  Go, 
YouTube,  Pandora,  Netflix,  HuluPlus,  RedBullTV  and  Vevo 
are  installed  on  the  tablet  device. 

Both  Chromecast  and  Tablet  are  connected  through  wireless 
to  the  D-Link  Wi-Fi  Router.  The  network  traffic  monitoring 
device  is  connected  to  the  router  via  an  ethernet  cable  to 
enhance  the  packet  forwarding  performance  of  router  and 
not  to  effect  the  wireless  spectrum  capacity  that  is  used  for 
streaming  with  Chromecast  and  Tablet  device. 

B.  Experiments,  Results  &  Findings 

In  our  experiments,  we  have  installed  Chromecast  App 
Software  Version  1.7.4  on  our  Nexus-7,  Android  4.4.4  tablet. 
The  Chrome  browser  installed  on  desktop,  used  Google- 
Cast  plug-in  version  14.805.0.6  for  TabCasting  experiments. 
Chromecast  device  itself  is  automatically  checking  for  updates 
each  time  it  boots  up,  the  latest  firmware  version  during  our 


experiments  was  17977.  By  examining  the  mirrored/captured 
network  packets,  we  wanted  to  investigate  the  connections 
that  are  opened,  kept-alive,  protocols  that  are  used,  packet 
flow  between  Chromecast  sender  apps  (resides  on  the  small 
screen  device)  and  the  Chromecast  receiver  app.  We  have 
found  several  interesting  points  that  might  be  either  improved 
or  extended  for  better  privacy  of  Chromecast  users.  Following 
are  the  different  experiments  that  have  been  done  to  examine 
the  network  packets  exchanged  under  different  scenarios. 

•  Experiment#!-  Tablet  device  casting  YouTube  video  to 
Chromecast:  YouTube  app  in  Anroid  tablet  has  a  cast 
to  Chromecast  button  enabled,  if  the  mobile  device  has 
previously  discovered  a  Chromecast  device  in  the  same 
network.  Once  tapped,  the  tablet  would  stop  showing  the 
video  in  the  small  screen  and  start  streaming  the  YouTube 
video  to  the  Chromecast  attached  larger  screen.  Tablet  de¬ 
vice  becomes  a  remote  control.  In  this  setting  the  control 
packets  such  as  play,  stop,  pause  etc.  are  sent  through 
clear-text  over  HTTP  from  tablet  to  YouTube  servers. 
This  would  pose  a  security  threat  and  provide  feasibility 
for  man-in-the-middle  attacks  and  replay-attacks.  The 
video  control  packets  are  sent  from  the  mobile  remote 
device  to  YouTube  servers  and  video  is  streamed  directly 
to  the  Chromecast.  When  looked  closer  to  the  control 
packets;  they  use  HTTP  POST,  HTTP  GET  methods  to 
control  the  video  played  on  Chromecast  attached  screen. 
Several  information  that  could  be  extracted  from  these 
packets  that  are  going  unencrypted  such  as;  the  google 
account  username  (if  logged  in  to  YouTube),  which  video 
is  being  watched  at  what  time  of  the  day,  what  kind  of 
Operating  System  and  which  version  is  installed  on  the 
remote  device  (Android  4.2.2,  iOS  etc),  brand  and  model 
of  remote  device  used  (brand=Asus,model=Nexus)  etc. 
Even  if  listened  passively  from  outside  home-network 
without  any  attacks,  this  information  could  be  seen  as 
a  leak  of  privacy. 

•  Experiment #2-  Vulnerability  Scanning  Chromecast: 
OpenVAS  (Open  Vulnerability  Assessment  System)  [20] 
is  an  open  source  vulnerability  scanner  that  is  updated 
daily  from  several  security  advisories.  As  of  writing  this 
paper,  it  has  about  35000  NVTs  (Network  Vulnerability 
Tests)  in  its  database.  There  are  multiple  components 
in  OpenVAS  Framework;  OpenVAS  Manager,  OpenVAS 
Scanner  and  Web  Interface.  In  our  testbed,  OpenVAS- 
7  is  installed  in  a  virtual  machine  running  on  an  Ubuntu 
host,  connected  in  the  same  local  network  as  Chromecast. 
We  run  the  most  rigorous  test  against  Chromecast  to 
scan  it  for  known  vulnerabilities.  However,  OpenVAS 
couldn’t  find  any  in  Chromecast.  Nmap  scan  listed  3  open 
ports  before  the  setup  in  Chromecast;  53,  8008  and  8009. 
Port  53  is  listening  for  DNS  queries  while  Port  8008  is 
listening  for  http  connections  and  port  8009  is  listed  as 
”ajpl3”  service.  Apps  are  communicating  with  the  device 
through  Port  8008. 

•  Experiment#3-  Cipher  Suites  used  by  Chromecast  de- 


vice:  Chromecast  uses  TLSvl.2  for  communicating  with 
TLS  capable  servers.  For  example;  Chromecast  commu¬ 
nicates  over  TLS v  1.2  while  downloading  an  image  to 
display  during  idle.  After  getting  the  IP  address  of  the 
content  server  from  Google’s  DNS,  Chromecast  and  the 
content  server  does  the  3-way  TCP  Handshake  which  is 
followed  by  Client  Hello  and  Server  Hello  TLS  messages. 

In  our  experiment  which  spanned  around  65  hours,  at  idle, 
all  the  internet  connections  to  the  remote  servers  which 
are  shown  at  the  Figure  8  utilized  TLS  vl.2,  except  NTP 
servers  and  google’ s  DNS  server. 

In  the  TLS  vl.2,  after  handshake,  client  and  server  sends 
Client  Hello  and  Server  Hello  Messages  in  order.  In 
Client  Hello  messages,  client  offers  a  list  of  Cipher 
Suites  that  it  supports.  Each  Cipher  Suite  defines  the 
key  exchange  algorithm  for  authentication,  as  well  as 
the  subsequently  used  symmetric  encryption  for  bulk 
encryption  and  integrity  check  algorithms  for  message 
authentication  code  calculation.  Server  responds  with  a 
Server  Hello  message  in  which  it  chooses  one  of  them 
out  of  the  client  supported  cipher  suites  list  [2].  In 
our  idle  experiment  that  spanned  65  hours,  Chromecast 
offered  two  different  Cipher  Suite  list  in  its  Client  Hello 
messages.  Lists  either  consisted  of  18  or  62  different 
suites.  About  99%  of  the  Client  Hello  messages  consisted 
of  18  cipher  suites,  where  the  tiny  1%  offered  62  different 
cipher  suites. 

Out  of  the  list  of  Cipher  Suites  supported  by 
Chromecast,  the  most  chosen  by  Google  Server’s  was 
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
which  was  also  listed  as  the  first  cipher  suite  in 
the  Chromecast’s  list,  by  99.29  %  of  the  time. 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 
and  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 
was  also  chosen  by  some  servers.  In  our  65  hour  idle 
experiment,  most  popular  cipher  suite  picked  up  by 
servers  2123  times  out  of  2138  times. 

Experiment#4-  Remote  server  orchestrated  local 
Chrome  TabCasting:  Chrome  TabCasting  is  an  experi¬ 
mental  future  that  is  used  through  the  GoogleCast  Plugin 
to  Chrome  Browser.  Chrome  Browser  extensions/plugins 
are  installed  from  the  Chrome  Web  Store.  After  installing 
this  extension  on  a  desktop  Chrome  Browser,  browser  can 
cast  the  view  of  a  tab  to  a  local  ChromeCast  device  if 
one  is  found  on  the  same  local  network.  The  interesting 
problem  here  that  was  found  after  capturing  the  network 
packets  is  that  the  desktop  casting  the  Chrome  Tab  is 
connecting  to  a  remote  STUN  [21],  [22]  server  and 
sending  the  cast  through  it  instead  of  just  sending  the 
packets  directly  to  the  Chromecast  device  locally. 

In  this  experiment  we  have  monitored  the  CPU  and 
memory  usage  of  a  TabCasting  machine.  We  have  used 
sysstat  tools  (pidstat)  to  capture  the  CPU  and  Memory 
usage  of  all  the  processes  that  Chrome  Browser  runs. 
Figure  3  shows  the  CPU  usage  of  the  chrome  processes 
while  tab-casting.  Figure  2  shows  the  total  Memory 
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Fig.  2.  Memory  usage  percentage  of  Desktop  machine  while  TabCasting  to 
Chromecast 


usage  of  the  Chrome  processes  while  tab-casting.  As 
figures  show,  TabCasting  is  overly  resource  consuming, 
especially  for  CPU  cycles.  CPU  cycles  are  calculated  with 
combining  total  usage  of  1 1  processes  belongs  to  Chrome 
browser;  which  are  assigned  to  run  on  different  CPU 
cores  in  parallel,  thus  total  CPU  usage  spikes  over  100% 
in  Figure  3.  Even  though  its  quite  useful  for  multimedia 
websites  that  do  not  a  have  a  Chromecast  app  yet,  this 
feature  is  still  experimental  and  not  even  close  to  optimal. 
A  router  with  simultaneous  dual  band  Wi-Fi  interfaces 
(2.4  and  5  GHz);  one  for  Chromecast,  other  for  the 
desktop  would  yield  much  better  performance. 
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3.  CPU  performance  on  the  Desktop  while  tabcasting  to  Chromecast 

Experiment#5-  Connections  maintained  when  Chrome¬ 
cast  is  running  in  idle:  Chromecast  maintains  a  couple 
of  connections  to  Google  servers  when  it  is  connected 
to  the  home  wireless  network,  but  not  streaming  video. 
One  connection  is  for  retrieving  the  images  that  are 
displayed  on  screen  as  a  wallpaper.  For  this  purpose, 
Chromecast  connects  to  a  Google  server  every  60  seconds 
to  download  the  next  image. 

These  images  are  retrieved  from  several  different  Google 
servers.  Chromecast  queries  the  Google’s  DNS  server  at 
8. 8. 8. 8,  which  in  turn  responds  with  couple  of  different  IP 
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Fig.  4.  Bar  Graph  of  Incoming  Packets  to  Chromecast  at  Idle 
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addresses  of  Google  content  servers  that  Chromecast  can 
connect  and  download  a  new  image  to  display  as  wallpa¬ 
per.  Chromecast  opens  a  connection  to  the  first  address 
in  the  DNS  response.  After  a  successful  TCP-Handshake 
they  set-up  a  TLS  vl.2  connection,  with  Chromecast 
offering  Cipher  Suites  for  authentication-bulk  encryption- 
decryption-Hashing  and  signature.  In  case  Chromecast 
would  keep  downloading  the  image  from  the  IP  address, 
it  keeps  the  connection  alive  with  a  TCP  Keep-Alive 
packet,  which  is  sent  45  seconds  after  wallpaper  image 
is  downloaded  from  the  server.  15  seconds  after  the  TCP 
Keep-Alive,  another  image  is  requested  from  the  same 
server  or  DNS  is  queried  again  to  get  another  IP  to  keep 
downloading  wallpaper  images. 

The  bar-graph  in  Figure  4  shows  us  the  total  amount  of 
data  incoming  to  Chromecast  device  per  minute.  This 
corresponds  to  the  wallpaper  images  that  are  displayed 
on  screen  when  the  Chromecast  is  not  used  actively  by 
another  local  remote  control  device.  Although  the  packets 
are  encrypted  with  TLS  v  1 .2,  someone  listening  the  traffic 
from  outside  can  differentiate  which  image  is  displayed 
on  the  screen  from  the  total  size  of  incoming  packets 
every  60  seconds. 

Data  from  a  3  days  of  network  trace  plotted  in  Fig¬ 
ure  5  shows  that  Chromecast,  when  running  in  idle,  is 
connecting  to  many  different  IP  addresses.  Even  though 
its  connecting  to  11  different  domains  as  shown  in 
Figure  8,  every  once  in  a  while  IP  address  corresponding 
to  the  same  domain  name  changes  for  load  balancing  & 
availability  reasons.  This  could  be  mistaken  as  a  malware 
leaking  information  from  internal  network  over-time. 
Figure  6,  shows  us  the  number  of  queries  per  domain 
name  sent  by  Chromecast  to  DNS  server  during  a  stream¬ 
ing  session  of  2  hours  from  YouTube.  When  Figure  6 
and  Figure  8  are  compared,  YouTube  streaming  session 
of  only  2  hours  establishes  connections  to  more  domains 
as  opposed  to  days  of  idle  streaming. 

To  examine  the  total  number  of  different  IP  address  that 
Chromecast  connects  during  the  same  2  hours  YouTube 


Domain  Names  in  Chromecast  DNS  Queries  vs.  Num  Of  Times  Queried 
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Fig.  6.  Chromecast  DNS  Queries  to  Google  DNS  server  while  streaming 
from  YouTube 


streaming  experiment;  Figure  7  is  plotted.  Chromecast 
connects  to  several  Google  content  servers  on  different 
IPs  for  image  download  on  idle  as  seen  in  Figure  5  and  for 
downloading  different  parts  of  stripped  video  as  depicted 
in  Figure  7  while  streaming  from  YouTube. 


Total  Number  of  Different  Machines  Connected  vs.  Time 
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Fig.  7.  Chromecast  connecting  to  different  machines  while  streaming  from 
YouTube 


Fig.  8.  Chromecast  DNS  Queries  at  idle  to  Google  DNS  server 


•  Experiment #6-  DNS  Queries  at  idle:  Chromecast  always 
uses  the  Google  DNS  Server,  8. 8. 8. 8.  As  show  in  Figure  8 
the  requests  at  idle  are  for  the  following  Address  Mapping 
Records(A); 

For  random  wallpaper  image  download  at  idle, 
first  Chromecast  queries  the  8. 8. 8. 8  Google 
DNS  server  for  an  Address  Mapping  Record(A) 
with  the  the  name  lh3.googleusercontent.com, 
lh4.googleusercontent.com,  lh5.googleusercontent.com 
or  lh6.googleusercontent.com.  Then,  DNS 
server  replies  with  couple  of  IP  addresses 
which  maps  to  the  cannonical  name  (CNAME) 
googlehosted.Lgoogleusercontent.com.  Also,  Address 
Mapping  Records(A)  for  clients3.google.com  and 
clients4.google.com  are  queried  from  DNS  server  and  it 
replies  with  usually  17  IP  records  for  canonical  name 
clients.Lgoogle.com.  These  are  also  used  for  wallpaper 
image  download. 

Another  DNS  query  Chromecast  sends  to  8. 8. 8. 8  asks  for 
the  IP  address  of  tools.google.com,  which  the  DNS  server 
replies  with  17  IP  addresses  mapped  to  the  Canonical 
Name  Record  (CNAME)  of  tools.Lgoogle.com.  However, 
this  query  is  not  common,  in  our  experiments  it  was 
queried  once  in  every  3-4  hours. 

Chromecast  queries  the  DNS  server  for  pool.ntp.org 
address.  DNS  server  replies  with  4  random  different  IP 
addresses.  In  our  experiments  the  interval  for  checking 
the  ntp  servers  for  Chromecast  is  not  frequent.  When 
Chromecast  first  checked  the  time,  its  clock  has  about  2 
seconds  of  time  drift  from  the  server.  There  is  not  regular 
pattern  for  Chromecast  to  check  for  time. 

Another  DNS  query  was  for  the  ajax.googleapis.com 
which  returned  an  IP  for  the  CNAME 
googleapis.Lgoogle.com.  This  query  was  made  only 
once  during  our  1  day  experiment.  Another  one  time 
query  was  for  www.gstatic.com. 

•  Experiment#? :  NTP  ( Network  Time  Protocol):  Chrome¬ 
cast  uses  NTP  protocol  after  it’s  rebooted  to  get  the 
current  time  through  a  NTP  server.  However,  there  are 
some  known  vulnerabilities  in  this  protocol,  specifically 


the  version  that  is  used  by  the  servers  that  Chromecast 
is  connecting  for  time  synchronization.  The  most  current 
stable  version  of  NTP  is  listed  as  4.2.6  at  ntp.org  official 
website  [18]  which  has  been  released  in  2011.  When 
Chromecast  queries  the  Network  Time  Server,  it  uses 
NTP  Version  3  which  was  released  in  1999  that  has 
long  been  deprecated.  Even  though  Chromecast  uses  an 
insecure  version  of  NTP,  this  connections  are  infrequent, 
as  seen  in  the  experiment  it  has  connected  to  an  NTP 
server  only  5  times  over  a  65  hours  of  idle  period. 

V.  Discussion 

Chromecast  Detection:  During  our  experiments,  some 
patterns  of  network  behaviour  are  found  to  be  specific  to 
Chromecast.  There  is  not  one  simple  formula  to  prove  the 
existence  of  Chromecast  behind  a  home-router,  however  the 
following  could  be  combined  to  come  up  with  a  tool  to  detect 
it. 

a)  MAC  address  of  Chromecast:  which  has  the  prefix  of 
(6C:AD:F8),  traces  back  to  AzureWave  Technologies,  Inc. 

b)  Chromecast  Hot  Spot  broadcasts  if  its  powered  up  but 
not  connected  to  the  home  Wi-Fi  router.  Which  is  also 
dangerous  because  anyone  nearby  searching  for  Wi-Fi 
routers  can  connect  to  it  and  change  its  settings. 

c)  Image  downloading  from  Google  servers  with  a  60  second 
interval  is  a  characteristic  behaviour  of  Chromecast  at  idle. 

d)  TLS  vl.2  Client  Hello  message  lists  almost  always  18 
Cipher  Suites  that  Chromecast  supports. 

e)  TabCasting  future  uses  the  STUN  protocol,  however,  in¬ 
stead  of  using  registered  UDP  port  number  3478  for  this 
protocol,  Chromecast  communicates  over  port  19302  with 
Google  STUN  server  which  is  for  Google  Talk  Voice  and 
Video  connections. 

These  are  not  exclusively  characteristic  features  of  Chrome¬ 
cast  but  they  could  be  combined  together  to  implement  a  tool 
that  can  accurately  detect  Chromecast  behind  a  NAT  device. 
ISP’s  could  make  use  of  this  tool  to  detect  their  users  who  are 
streaming  videos  onto  a  Chromecast  behind  their  home-router. 

VI.  Conclusion  and  Future  Work 

We  examined  the  network  packets  exchanged  between  the 
smaller  remote  control  device  and  the  Chromecast  attached 
larger  screen.  While  Chromecast  encrypts  most  of  the  content, 
remote  control  device  sends  control  packets  to  the  remote 
servers  in  the  clear-text,  which  makes  it  vulnerable  to  several 
attacks.  Besides,  it  leaks  personal  information  of  the  user  to 
outside  network,  raising  privacy  concerns.  We  have  listed  the 
protocols  used  by  Chromecast  and  their  known  vulnerabilities. 
We  also  proposed  a  simple  method  to  detect  the  existance  of 
a  Chromecast  device  behind  a  home-network. 

Future  work  includes  but  not  limited  to;  implementation  of 
Chromecast  detection  tool,  a  tool  for  injecting  control  packets 
like  stop,  pause,  restart,  for  ongoing  YouTube  sessions  and 
casting  new  videos  to  Chromecast  attached  screen,  executing 
a  DoS  attack  based  on  STUN  protocol  weaknesses,  examining 
network  communication  of  official  Chromecast  supported  apps 


on  the  market,  and  comparing  the  security  of  Other  HDMI  [24]  Yajin  Zhou  and  Xuxian  Jiang.  Dissecting  android  malware:  Character- 

Streaming  sticks  from  Amazon  Netgear  and  Roku  ization  and  evolution.  In  IEEE  Symposium  on  Security  and  Privacy, 

B  ’  5  •  pages  95_1099  2012. 
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Abstract — Chromecast  is  a  small,  system-on-chip  device,  that 
plugs  into  the  HDMI  port  of  a  larger  screen  and  turns  it  into 
a  smart  screen.  It  is  designed  for  multimedia  streaming  in  a 
home-network  environment.  By  setting  up  Chromecast,  you  can 
stream  videos  onto  a  larger  screen  and  control  it  from  a  mobile 
device  such  as  a  smart-phone,  tablet  or  a  laptop.  We  examined 
the  network  packets  exchanged  between  the  smaller  remote 
control  device  and  the  Chromecast  attached  larger  screen.  While 
Chromecast  encrypts  most  of  the  content,  remote  control  device 
sends  control  packets  to  the  remote  servers  in  the  clear-text, 
which  makes  it  vulnerable  to  reply-attacks  or  session-hijacking 
attacks.  Besides,  data  transmission  pattern  leak  personal  infor¬ 
mation  outside  of  the  home-network,  raising  privacy  concerns. 
Network  protocols  used  by  Chromecast  are  investigated  and 
known  vulnerabilities  are  listed.  A  method  to  detect  the  existence 
of  Chromecast  behind  a  home-router  is  proposed. 
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Fig.  1.  Experimental  Network  Setup 


I.  Introduction 

With  the  recent  improvements  in  networking  and  multime¬ 
dia  technology  in  the  last  couple  of  years,  streaming  high 
definition  audio  and  video,  whether  its  local  or  remote,  became 
increasingly  popular  in  a  home-network  environment.  Chrome¬ 
cast  [I]  is  a  cost  effective  way  of  streaming  multimedia,  either 
from  Internet  or  locally  stored,  onto  a  larger  screen.  Its  an 
HDMI  stick  that  connects  to  HDMI  port  and  communicates 
over  Wi-Fi. 

In  this  paper,  we  have  evaluated  the  network  protocols  used 
by  Chromecast;  packet  flow  between  client,  Chromecast  and 
external  servers;  and  examined  the  network  communications 
in  a  blackbox  manner  from  security  and  privacy  perspective. 

The  rest  of  the  paper  is  organized  as  follows:  Experimental 
testbed  setup  and  experimental  results  are  given  in  Section  II. 
We  discuss  a  method  to  detect  Chromecast  in  Section  III. 
Conclusion  of  the  paper  is  presented  in  Section  IV. 

II.  Experimental  Results 


Router  hardware  is  flashed  with  open-source  Open-Wrt 
[4]  firmware.  Open-Wrt  [4]  is  a  Linux  based  alternative 
OpenSource  firmware  suitable  for  a  great  variety  of  WLAN 
routers  and  embedded  systems.  We  made  use  of  iptables  [2] 
firewall  that  is  embedded  into  most  linux  based  kernels.  Open- 
Wrt  kernel  comes  with  iptables  firewall,  however,  because 
of  memory  space  limitations,  Open-Wrt  excluded  the  module 
required  for  port-mirroring  functionality.  We  have  customized 
and  built  the  source  after  adding  the  support  for  iptables  kernel 
module  iptTEE.  With  the  iptTEE  support,  it  was  possible  to 
mimic  the  high-end  router  capability  called  ”Port-Mirroring” 
with  our  low-end  router. 

By  adding  rules  to  mangle  table  of  iptables  firewall,  to  send 
a  copy  of  each  packet  destined  or  sourced  from  the  Chromecast 
device  IP,  we  were  able  to  monitor  the  network  traffic. 

The  following  iptables  commands  are  used  to  mirror  all  of 
the  network  communication; 

$  iptables  -t  mangle  -A  POSTROUTING  -s  192.168.1.0/24  -j  TEE  — gateway  192.168.1.154 
$  iptables  -t  mangle  -A  POSTROUTING  -d  192.168.1.0/24  -j  TEE  — gateway  192.168.1.154 


In  this  section,  we  provide  and  discuss  the  results  of 
experiments  executed  on  the  test-bed  shown  in  Figure  1. 

A.  Home-Network  Testbed  Setup 

In  our  experimental  testbed  we  had;  a  Chromecast  device 
plugged  into  the  HDMI  port  of  an  LCD  monitor,  an  Android 
tablet  as  Chromecast  remote  control  device,  and  a  laptop  as 
a  traffic  monitoring  device  that  are  all  connected  to  a  D-Link 
DIR-615  v.E3  Wireless  Router  as  shown  in  Figure  1. 


The  first  firewall  rule  here,  sends  a  copy  of  all  locally 
generated  packets  to  the  gateway  machine  at  IP  address 
192.168.1.154,  which  is  running  wireshark  to  capture  the 
packets  while  second  rule  mirrors  a  copy  of  each  packet  that  is 
destined  to  a  local  machine,  coming  from  an  outside  machine. 

B.  Experiments,  Results  &  Findings 

By  examining  the  mirrored/captured  network  packets,  we 
wanted  to  investigate  the  connections  that  are  opened,  kept- 


alive,  protocols  that  are  used,  packet  flow  between  Chromecast 
sender  apps  (resides  on  the  small  screen  device)  and  the 
Chromecast  receiver  app.  We  have  found  several  interesting 
points  that  might  be  either  improved  or  extended  for  better 
privacy  of  Chromecast  users. 

•  Experiment #1-  Casting  YouTube  video  to  Chromecast: 
The  control  packets  such  as  play,  stop,  pause  etc.  are  sent 
through  clear-text  over  HTTP  from  tablet  to  YouTube 
servers.  This  would  pose  a  security  threat  and  pro¬ 
vide  feasibility  for  man-in-the-middle  attacks  and  replay- 
attacks.  Unencrypted  packets  leaked  information  such 
as;  google  account  username  (if  logged-in  to  YouTube), 
name  and  time  of  the  video  being  watched,  Operating 
System  and  it’s  version  installed  on  the  remote  device 
(Android  4.2.2,  iOS  etc),  brand  and  model  of  remote 
device  (brand=Asus,model=Nexus)  etc. 

•  Experiment#2-  Vulnerability  Scanning  Chromecast: 
OpenVAS  (Open  Vulnerability  Assessment  System)  [5]  is 
an  open  source  vulnerability  scanner  that  is  updated  daily 
from  several  security  advisories.  We  run  the  most  rigorous 
tests  against  Chromecast  to  scan  it  for  known  vulnerabil¬ 
ities,  however,  OpenVAS  couldn’t  find  any.  On  the  other 
hand,  nmap  scan  listed  2  open  ports  in  Chromecast;  8008 
and  8009.  Port  8008  is  listening  for  http  connections  and 
port  8009  is  listed  as  ”ajpl3”  service. 

•  Experiment #3-  Cipher  Suites  used  by  Chromecast: 
Chromecast  offered  two  different  Cipher  Suite  lists  in  its 
Client  Hello  messages.  Lists  consisted  of  either  18  or  62 
different  suites.  About  99%  of  the  Client  Hello  messages 
consisted  of  18  cipher  suites,  where  the  tiny  1%  offered 
62  different  cipher  suites.  This  list  of  offered  cipher  suites 
could  be  used  to  detect  a  Chromecast  behind  a  router. 

•  Experimented-  Remote  server  orchestrated  local 
Chrome  TabCasting:  The  desktop  casting  the  Chrome 
browser  tab  is  connecting  to  a  remote  STUN  [6]  server 
and  sending  the  cast  through  it  instead  of  sending  the 
packets  locally,  however,  STUN  protocol  has  several 
known  vulnerabilities  listed. 

•  Experiment#5-  Connections  maintained  at  idle  state: 
Chromecast  maintains  a  couple  of  connections  to  Google 
servers  when  it  is  connected  to  the  home  wireless  net¬ 
work,  but  not  streaming  video.  One  connection  is  for 
retrieving  the  images  that  are  displayed  on  screen  as  a 
wallpaper.  For  this  purpose,  Chromecast  connects  to  a 
Google  server  every  60  seconds  to  download  the  next 
image.  Although  the  packets  are  encrypted  with  TLS 
vl.2,  someone  listening  the  traffic  from  outside  can 
differentiate  which  image  is  displayed  on  the  screen  from 
the  total  size  of  incoming  packets  every  60  seconds. 

•  Experiment#6-  DNS  Queries  at  idle  state:  Chromecast 
always  uses  the  Google  DNS  Server,  8. 8. 8. 8.  For 
random  wallpaper  image  download  at  idle,  an  Address 
Mapping  Record(A)  for  lh3.googleusercontent.com, 
lh4.googleusercontent.com,  Ili5.googleusercontent.com 
or  lh6.googleusercontent.com,  clients3.google.com  and 


clients4.google.com  are  requested.  Other  DNS  queries 
asked  for  the  IP  addresses  of  tools.google.com  and 
pool,  ntp.org. In  our  experiments  the  interval  for  checking 
the  ntp  servers  for  Chromecast  is  not  frequent.  Another 
DNS  query  was  for  the  ajax.googleapis.com  This  query 
was  made  only  once  during  our  1  day  experiment. 
Another  one  time  query  was  for  www.gstatic.com. 

•  Experiment#?:  NTP  ( Network  Time  Protocol ):  Chrome¬ 
cast  uses  NTP  [3]  protocol  for  getting  the  current  time 
through  an  NTP  server  each  time  it’s  rebooted.  However, 
there  are  some  known  vulnerabilities  in  this  protocol, 
specifically  the  version  that  is  used  by  the  servers  that 
Chromecast  is  connecting  for  time  synchronization. 

III.  Discussion 

During  our  experiments,  some  patterns  of  network  be¬ 
haviour  are  found  to  be  specific  to  Chromecast.  The  following 
could  be  combined  to  come  up  with  a  tool  to  detect  it. 

a)  MAC  address  of  Chromecast  has  the  prefix  of  (6C:AD:F8), 
traces  back  to  AzureWave  Technologies,  Inc. 

b )  Chromecast  Hot  Spot  broadcasts  if  its  powered  up  but  not 
connected  to  the  home  Wi-Fi  router.  Which  is  dangerous 
because  anyone  nearby  searching  for  Wi-Fi  routers  can 
connect  to  it  and  change  its  settings. 

c)  Image  downloading  from  Google  servers  with  a  60  second 
interval  is  a  characteristic  behaviour  of  Chromecast  at  idle. 

d)  TLS  vl.2  Client  Hello  message  lists  almost  always  18 
Cipher  Suites  that  Chromecast  supports. 

e)  TabCasting  future  uses  the  STUN  protocol,  however,  in¬ 
stead  of  using  registered  UDP  port  number  3478  for  this 
protocol,  Chromecast  communicates  over  port  19302  with 
Google  STUN  server  which  is  for  Google  Talk  Voice  and 
Video  connections. 

IV.  Conclusion 

We  examined  the  network  packets  exchanged  between  the 
smaller  remote  control  device  and  the  Chromecast  attached 
larger  screen.  While  Chromecast  encrypts  most  of  the  content, 
remote  control  device  sends  control  packets  to  the  remote 
servers  in  the  clear-text,  which  makes  it  vulnerable  to  several 
attacks.  Besides,  it  leaks  personal  information  of  the  user  to 
outside  network,  raising  privacy  concerns.  We  have  listed  the 
protocols  used  by  Chromecast  and  their  known  vulnerabilities. 
We  also  proposed  a  simple  method  to  detect  the  existance  of 
a  Chromecast  device  behind  a  home-network. 
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